From owner-freebsd-ports@FreeBSD.ORG Mon Jun 11 05:54:31 2012 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8E6A106566B for ; Mon, 11 Jun 2012 05:54:31 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A9A4F8FC16; Mon, 11 Jun 2012 05:54:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5B5sVmt020319; Mon, 11 Jun 2012 05:54:31 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5B5sVgG020318; Mon, 11 Jun 2012 05:54:31 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Mon, 11 Jun 2012 07:54:29 +0200 From: Baptiste Daroussin To: Matthew Seaman Message-ID: <20120611055428.GS60433@ithaqua.etoilebsd.net> References: <4FD586EF.20100@infracaninophile.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s9pXJW6w71JX4l3T" Content-Disposition: inline In-Reply-To: <4FD586EF.20100@infracaninophile.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports Subject: Re: OPTIONSng and OPTIONS_SINGLE, OPTIONS_MULTI X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 05:54:32 -0000 --s9pXJW6w71JX4l3T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 11, 2012 at 06:49:35AM +0100, Matthew Seaman wrote: >=20 > Dear all, >=20 > In the new OPTIONS framework, we have some great new constructs for > doing really useful stuff constraining what different combinations of > options may be selected. >=20 > One of these is OPTIONS_SINGLE which implements a 'radio button' > permitting the choice of 1 item out of N options. Well, actually, it > allows choosing 1 out of N in its generic form. Eg. >=20 > OPTIONS_SINGLE=3D EXAMPLE > OPTIONS_SINGLE_EXAMPLE=3D FOO BAR BAZ BLURFL >=20 > (permits at exactly one out of FOO BAR BAZ BLURFL to be selected) >=20 > Now, supposing the requirement is that 'at most one of those options' > should be selected. Currently that is done like this: >=20 > OPTIONS_DEFINE=3D EXAMPLE > OPTIONS_SINGLE=3D EXAMPLE > OPTIONS_SINGLE_EXAMPLE=3D FOO BAR BAZ BLURFL >=20 > (requires at most one of FOO BAR BAZ BLURFL to be selected) >=20 > I find this unsatisfactory, partly for aesthetic reasons and partly > because it doesn't make much sense to me. Why should adding a normal > on/off option with the same name as the SINGLE group mean you can choose > either zero or one of these? It might work if the way options were > presented to the user was more sophisticated than dialog(1), so you > could grey-out the SINGLE options when the controlling DEFINE is turned > off, but dialog doesn't do that. >=20 > Surely it is more sensible to say that OPTIONS_SINGLE is strictly > 'choose one from these options.' Then you can implement 'zero or one of > these options' by: >=20 > OPTIONS_SINGLE=3D EXAMPLE > OPTIONS_SINGLE_EXAMPLE=3D FOO BAR BAZ BLURFL NONE_OF_THE_ABOVE >=20 > Similar arguments apply to OPTIONS_MULTI. >=20 > OPTIONS_MULTI=3D EXAMPLE2 > OPTIONS_MULTI_EXAMPLE2=3D QUX QUUX QUUUX >=20 > means 'choose at one or more out of QUX QUUX QUUUX' You can change that > to mean 'choose any number out of QUX QUUX QUUUX' by: >=20 > OPTIONS_DEFINE=3D EXAMPLE2 > OPTIONS_MULTI=3D EXAMPLE2 > OPTIONS_MULTI_EXAMPLE2=3D QUX QUUX QUUUX >=20 > However, this is syntactically identical to just using normal on/off > options with no constraints between them: >=20 > OPTIONS_DEFINE=3D QUX QUUX QUUUX >=20 > so that's just redundant. >=20 > What do people think? >=20 > Cheers, >=20 > Matthew >=20 >=20 > --=20 > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > JID: matthew@infracaninophile.co.uk Kent, CT11 9PW >=20 >=20 I 100% agree on that, it should be quite easy to do just needs 2 new names = :) And a patch we shouldn't be complicated (while writting the patch be careful than some ports are already using SINGLE the aesthetic way and need to be patched at the same time. regards, Bapt --s9pXJW6w71JX4l3T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/ViBQACgkQ8kTtMUmk6ExCnQCgv9SspcXZQopSYIzexXehNbCG GqQAn3uQ8/mcggs6/ZLZw6hYdjHpyNe4 =JJWp -----END PGP SIGNATURE----- --s9pXJW6w71JX4l3T--