On Wed, Feb 06, 2013 at 10:19:32AM +0100, Baptiste Daroussin wrote: > 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 >
Lots of people are asking to change the name saying they don't like USE_FEATURES here is the list of proposition that have been made, please vote for you favorites :) USE_FEATURES: keep it as is it is cool USE_FEATURE: please singular USES: Why bother with something longer USE: singular I said FEATURES: Why keeping USE? FEATURE: I told you singular! regards, Bapt
pgpwGXJ2TGVom.pgp
Description: PGP signature
