Re: emulators/mame: Increasing option granularity woes

From: Alastair Hogge <agh_at_riseup.net>
Date: Tue, 27 Feb 2024 02:43:27 UTC
On 2024-02-23 15:05, Gleb Popov wrote:

Hi Gleb,

> On Fri, Feb 23, 2024 at 5:51 AM Alastair Hogge <agh@riseup.net> wrote:
>>
>> Hello,
>>
>> The current in-tree port of mame, 0.261, is built around the core
>> multi-emulation framework, which results in the usual mega monolithic
>> mame binary. There are options for TOOLS, which include two other
>> emulators. The current upstream release, 0.262 has enabled separation of
>> mame from the rest of the project—TOOLS can now be built separately. I
>> would like to reflect this in the Port, however, that means moving the
>> two added emulators (LaserDisk player, and Netlist resolver) out of
>> TOOLS (which I think the correct path to take). Considering the new
>> upstream build pattern, I would like to configure the Port to option any
>> of the emulators, and existing TOOLS. The problem I am facing, the three
>> emulators require the same (or close to it) runtime config/resources,
>> the assets are currently covered by the do-install target[1], how do I
>> cover the assets in the Port, specifically in the pkg-plist to be
>> conditioned on either of 3 potential emulator options? Should I add an
>> option MAMEDATA?
> 
> You're almost right. Indeed there is no need in the user-visible
> option, but you want all other machinery to kick in.
> Basically, it boils down to
> 
> .if somecond
> PLIST_SUB+=    MAMEDATA=
> .else
> PLIST_SUB+=    MAMEDATA="@comment "
> .endif

The mess I have at the moment.

> where "somecond" defines if the files should be present in the
> package. For OPTIONS (and when OPTIONS_SUB=yes is present [1]) it
> happens automatically.
> 
> If you end up with "somecond" being in form "${PORT_OPTIONS:MFOO} ||
> ${PORT_OPTIONS:MBAR}" then you could simplify it even more
> 
> FOO_PLIST_SUB= MAMEDATA=
> FOO_PLIST_SUB_OFF= MAMEDATA="@comment "
> BAR_PLIST_SUB= MAMEDATA=
> BAR_PLIST_SUB_OFF= MAMEDATA="@comment "

This is brilliant, I think I was getting confused with the documentation
referring to OPTIONS/OPT for conditioning PLIST, and an User visible
option is what I wanted to avoid. I am testing this now, and it is far
more elegant, however, I do not know how that translates to Makefile
targets, like do-install-NON_USER_FACING_OPT-on. Currently the Makefile
target is of the ".if somecond FOO= .else BAR= .endif" form.

Thanks a billion!
Alastair