[CFT+BRAINSTORM] One USE_ to rule them all

[Baptiste Daroussin]

On Tue, Feb 05, 2013 at 06:47:34PM -0500, Eitan Adler wrote:
> On 5 February 2013 18:24, Baptiste Daroussin <bapt at 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
-------------- 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/83baf776/attachment.sig>