Date: Fri, 21 Jun 2013 10:04:51 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Alexey Dokuchaev <danfe@nsu.ru> Cc: ports@freebsd.org Subject: Re: Proposal: further OptionsNG improvements Message-ID: <20130621080451.GL23721@ithaqua.etoilebsd.net> In-Reply-To: <20130618162708.GA34175@regency.nsu.ru> References: <20130618160037.GA26677@regency.nsu.ru> <20130618162708.GA34175@regency.nsu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--Xb8pJpF45Qg/t7GZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 18, 2013 at 11:27:08PM +0700, Alexey Dokuchaev wrote:
> On Tue, Jun 18, 2013 at 11:00:37PM +0700, Alexey Dokuchaev wrote:
> > Hi there,
> >=20
> > Now as I understand old-skool OPTIONS knob support is removed, can we do
> > something about ugliness of newish OPTIONS_DEFINE[_arch]/OPTIONS_DEFAULT
> > [_arch] pair of knobs?
> >=20
> > I am thinking about the following syntax (using now free-again OPTIONS
> > knob, instead of several OPTIONS_DEFINE/OPTIONS_DEFAULT definitions):
> >=20
> > OPTIONS=3D FOO:on BAR ASM/i386,amd64:on,powerpc ...
> >=20
> > Ditto for OPTIONS_RADIO et al. This will also be kind of reminiscent to
> > existing USE_AUTOCONF and recently added USES knob.
> ^^^^^^^^^^^^
> Should be USE_AUTOTOOLS of course, sorry. Per-architecture syntax can be
> quite flexible, depeding on what's easier to parse:
>=20
> ASM/i386,amd64:on,powerpc or
> ASM/i386:off,amd64:on,powerpc:off or
> ASM/powerpc,{i386,amd64}:on etc.
>=20
> ./danfe
Sorry it took time for me to reply, after we last talk about this, I though=
t a
lot about this, and while in principe I do like the idea, I have a couple of
concerns:
1: this reduces lots of flexibility we now have with the new options framew=
ork,
well at the least the patch should make sure it doesn't reduce it for insta=
nce,
it should work properly with:
OPTIONS_EXCLUDE and OPTIONS_SLAVE.
if should be able to handle properly the folowing situation:
OPTIONS_DEFINE=3D DOCS X11
OPTIONS_DEFINE_i386=3D MYSQL PGSQL
OPTIONS_DEFINE_amd64=3D MYSQL PGSQL
OPTIONS_DEFAULT_i386=3D MYSQL
OPTIONS_DEFAULT_amd64=3D PGSQL
OPTIONS_EXCLUDE_powerpc=3D X11
This is things I haven't been able to imagine in a concise/understandable s=
yntax
like the one you are proposing, if we are able to do it then fine for me :)
2: I'm concern about the parsing performance, not that I have tested anythi=
ng,
but it just looks like it would be less performant for make(1) to parse pro=
perly
all this, this should be measured to at least know the inpact in the package
building clusters and index building boxes once everything will be converte=
d.
regards,
Bapt
--Xb8pJpF45Qg/t7GZ
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
iEYEARECAAYFAlHECSMACgkQ8kTtMUmk6EwLuQCcD+0YurjrBaAPnXK4cStjr1SB
2r8AoKx9Jqj2DirxwXZlrL7fzr0d32Vr
=TaL3
-----END PGP SIGNATURE-----
--Xb8pJpF45Qg/t7GZ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130621080451.GL23721>