From nobody Tue Feb 27 02:43:27 2024 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TkMHR2pSsz5CDty for ; Tue, 27 Feb 2024 02:43:31 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.riseup.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TkMHP6rK3z41w9; Tue, 27 Feb 2024 02:43:29 +0000 (UTC) (envelope-from agh@riseup.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=lrZ9qUv1; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=agh@riseup.net Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx1.riseup.net (Postfix) with ESMTPS id 4TkMHM6J3wzDqNV; Tue, 27 Feb 2024 02:43:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1709001807; bh=ceD/Zm5W4J26ozCRsBA37G8am7nZc0BZMcO/ZWdakDo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lrZ9qUv1eLvik8wo+Z1oP8kTG9iTHdSRcbjm3x/2CawubJCY3KtnAqGAeM0gU/mG0 YS4dfZ3V33sNnWPfDpnhRXnYbejXga0/D96DzL379cKdYMtMwEsbbMzWLd9wor9D7a F4jxPAvpqrPemqvy1GIrnYmOcumXYWb3qJn3n9gc= X-Riseup-User-ID: 4EFBA8515149E9AC63E3797D65C720DFAB95D1E6847966D23CAEC723332AA1EB Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4TkMHM4tKvzFsbK; Tue, 27 Feb 2024 02:43:27 +0000 (UTC) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Tue, 27 Feb 2024 02:43:27 +0000 From: Alastair Hogge To: Gleb Popov Cc: freebsd-ports@freebsd.org Subject: Re: emulators/mame: Increasing option granularity woes In-Reply-To: References: <0f7f4f5675d1e75e504ad67d963e8874@riseup.net> Message-ID: <137c5ccbdaa6ca8e5913771d0ed737d7@riseup.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; R_SPF_ALLOW(-0.20)[+a:mx1.riseup.net]; RWL_MAILSPIKE_GOOD(-0.10)[198.252.153.129:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.129:from]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[riseup.net:dkim]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[riseup.net:+] X-Rspamd-Queue-Id: 4TkMHP6rK3z41w9 On 2024-02-23 15:05, Gleb Popov wrote: Hi Gleb, > On Fri, Feb 23, 2024 at 5:51 AM Alastair Hogge 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