Re: emulators/mame: Increasing option granularity woes
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