Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Feb 2013 10:19:32 +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:  <20130206091932.GF1268@ithaqua.etoilebsd.net>
In-Reply-To: <20130205232407.GM88651@ithaqua.etoilebsd.net>
References:  <20130204181946.GF67687@ithaqua.etoilebsd.net> <511003B3.90600@gmail.com> <20130205232407.GM88651@ithaqua.etoilebsd.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--3oCie2+XPXTnK5a5
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 06, 2013 at 12:24:07AM +0100, Baptiste Daroussin wrote:
> 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
>=20
> patch has been updated to be able to support the following:
>=20
> USE_FEATURES=3D	foo:bla
> that will 1/ load foo.mk, 2/ create a variable: FEATURE_foo=3D bla
>=20
> So that you can do virtually any thing you want :)

As I have been asked here is an example converting USE_GETTEXT to the new
feature:
http://people.freebsd.org/~bapt/gettext.mk
to be use as the following:

USE_FEATURES=3D	gettext
or
USE_FEATURES=3D	gettext:run
or
USE_FEATURES=3D	gettext:build

>=20
> regards,
> Bapt



--3oCie2+XPXTnK5a5
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAlESICQACgkQ8kTtMUmk6ExfjwCeNaFbgDZOkbapbDeakeAfJpzK
pAgAoIICh/WU/nUN9EV+fBl+SJUk25j1
=TNBA
-----END PGP SIGNATURE-----

--3oCie2+XPXTnK5a5--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130206091932.GF1268>