On Tue, Feb 05, 2013 at 06:47:34PM -0500, Eitan Adler wrote: > On 5 February 2013 18:24, Baptiste Daroussin <b...@freebsd.org> 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 :) > > IMHO this is pointless extra processing. I'd prefer to see > FEATURE_foo be manually inserted. >
This processing is only 2 lines of code and allows to make sure there is some kind of consistency added to the usage of USE_FEATURES. regards, Bapt
pgppJDXPEJlJ2.pgp
Description: PGP signature
