[CFT+BRAINSTORM] One USE_ to rule them all

Baptiste Daroussin bapt at FreeBSD.org
Wed Feb 6 09:19:37 UTC 2013


On Wed, Feb 06, 2013 at 12:24:07AM +0100, Baptiste Daroussin wrote:
> On Mon, Feb 04, 2013 at 07:53:39PM +0100, René Ladan wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 04-02-2013 19:19, Baptiste Daroussin wrote:
> > > Hi,
> > > 
> > > I have some improvements to the ports tree to propose, and I'm
> > > looking for testers/opinions
> > > 
> > > First let me explain:
> > > 
> > > I want to introduce a new USE_FEATURES macro into the ports tree
> > > 
> > > 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.
> > > 
> > > What I expect in long term is to get a more readable bsd.port.mk &
> > > friends, meaning easier to maintain
> > > 
> > > I except some performance improvements given that make will have to
> > > parse less things.
> > > 
> > > I also expect less complexity if bsd.*.mk code.
> > > 
> > > 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=
> > > something
> > > 
> > > 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.
> > > 
> > > each features/*.mk is itself protected by a variable to avoid multi
> > > loading of the same file
> > > 
> > > if a feature depends on another one the feature itself just have to
> > > ".include" the other one.
> > > 
> > This sounds like a good idea to me.
> > 
> > > As a proof of concept I made the following: USE_FEATURES=	gmake
> > > (with a compatibility for USE_GMAKE to allow migration) 
> > > USE_FEATURES=	iconv (with a compatibility for USE_ICONV to allow
> > > migration) USE_FEATURES=	motif (with no compatibility as I have
> > > switched all the USE_MOTIF ports to use it) USE_FEATURES=	fise
> > > (with no compatibility as I have switched all the USE_FUSE to use
> > > it) USE_FEATURES=	display (with no compatibilify as I have switched
> > > all the USE_DISPLAY to use it) USE_FEATURES=	pathfix (which is the
> > > equivalent of USE_GNOME= gnomehack without the need to loading the
> > > whole bsd.gnome.mk)
> > > 
> > > 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)
> > > 
> > Are you saying that some USE_BLAH=yes will stick around or do I
> > misunderstand?
> > 
> > Another question: for USE_BLAH=yes the logical transformation would be
> > USE_FEATURES=BLAH but what about USE_FOO=BLAH ? Would
> > USE_FEATURES=FOO/BLAH (possibly another separator) or
> > USE_FEATURES=BLAH be more sensible?
> > 
> 
> patch has been updated to be able to support the following:
> 
> USE_FEATURES=	foo:bla
> that will 1/ load foo.mk, 2/ create a variable: FEATURE_foo= bla
> 
> 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=	gettext
or
USE_FEATURES=	gettext:run
or
USE_FEATURES=	gettext:build

> 
> regards,
> Bapt


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20130206/69c885ab/attachment.sig>


More information about the freebsd-ports mailing list