Date: Wed, 6 Feb 2013 00:24:07 +0100 From: Baptiste Daroussin <bapt@FreeBSD.org> To: =?iso-8859-1?Q?Ren=E9?= Ladan <r.c.ladan@gmail.com> Cc: freebsd-ports@freebsd.org Subject: Re: [CFT+BRAINSTORM] One USE_ to rule them all Message-ID: <20130205232407.GM88651@ithaqua.etoilebsd.net> In-Reply-To: <511003B3.90600@gmail.com> References: <20130204181946.GF67687@ithaqua.etoilebsd.net> <511003B3.90600@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--F7w+4yMapWozG0Ib Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 04, 2013 at 07:53:39PM +0100, Ren=E9 Ladan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 04-02-2013 19:19, Baptiste Daroussin wrote: > > Hi, > >=20 > > I have some improvements to the ports tree to propose, and I'm > > looking for testers/opinions > >=20 > > First let me explain: > >=20 > > I want to introduce a new USE_FEATURES macro into the ports tree > >=20 > > The goal of this macros is to be able to standardize how we call > > all the USE_* things as well as creating some "load on demand" code > > for a corresponding feature. > >=20 > > What I expect in long term is to get a more readable bsd.port.mk & > > friends, meaning easier to maintain > >=20 > > I except some performance improvements given that make will have to > > parse less things. > >=20 > > I also expect less complexity if bsd.*.mk code. > >=20 > > What will have is all/most of the code corresponding to a > > USE_SOMETHING right now will endup in a Mk/features/something.mk > > which will be loaded only if the ports defines: USE_FEATURES=3D > > something > >=20 > > the loading is done at the very early stage of bsd.port.post.mk to > > allow one to load modify USE_FEATURES depending on some options > > etc. > >=20 > > each features/*.mk is itself protected by a variable to avoid multi > > loading of the same file > >=20 > > if a feature depends on another one the feature itself just have to > > ".include" the other one. > >=20 > This sounds like a good idea to me. >=20 > > As a proof of concept I made the following: USE_FEATURES=3D gmake > > (with a compatibility for USE_GMAKE to allow migration)=20 > > USE_FEATURES=3D iconv (with a compatibility for USE_ICONV to allow > > migration) USE_FEATURES=3D motif (with no compatibility as I have > > switched all the USE_MOTIF ports to use it) USE_FEATURES=3D fise > > (with no compatibility as I have switched all the USE_FUSE to use > > it) USE_FEATURES=3D display (with no compatibilify as I have switched > > all the USE_DISPLAY to use it) USE_FEATURES=3D pathfix (which is the > > equivalent of USE_GNOME=3D gnomehack without the need to loading the > > whole bsd.gnome.mk) > >=20 > > The very long term goal will be to switch as much code as possible > > to be turn into a feature (when it makes sens of course) > >=20 > Are you saying that some USE_BLAH=3Dyes will stick around or do I > misunderstand? >=20 > Another question: for USE_BLAH=3Dyes the logical transformation would be > USE_FEATURES=3DBLAH but what about USE_FOO=3DBLAH ? Would > USE_FEATURES=3DFOO/BLAH (possibly another separator) or > USE_FEATURES=3DBLAH be more sensible? >=20 patch has been updated to be able to support the following: USE_FEATURES=3D foo:bla that will 1/ load foo.mk, 2/ create a variable: FEATURE_foo=3D bla So that you can do virtually any thing you want :) regards, Bapt --F7w+4yMapWozG0Ib Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlERlJcACgkQ8kTtMUmk6ExREwCgt59r+B0PbNcpLwt3hPutIcNx ZJsAnRSa1CF1WkSp0r84+BUI9NPa2Ab4 =h9Y0 -----END PGP SIGNATURE----- --F7w+4yMapWozG0Ib--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130205232407.GM88651>