Date: Mon, 04 Feb 2013 19:53:39 +0100 From: =?ISO-8859-1?Q?Ren=E9_Ladan?= <r.c.ladan@gmail.com> To: freebsd-ports@freebsd.org Subject: Re: [CFT+BRAINSTORM] One USE_ to rule them all Message-ID: <511003B3.90600@gmail.com> In-Reply-To: <20130204181946.GF67687@ithaqua.etoilebsd.net> References: <20130204181946.GF67687@ithaqua.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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? > The USE_FEATURES itself: > http://people.freebsd.org/~bapt/features.diff > > The modified ports for the PoC: > http://people.freebsd.org/~bapt/features-chase.diff > You could commit the header updates already if possible, which also makes the patch more readable. Regards, René -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJREAOzAAoJEKipqUGAIxKQLXsQAJDecygfd5cWSbKtt7P5yBGm 1xqPKiPI6bbyGzykob72woPFWK9bl0mS+JN0TYEaecHyQDyc59BauuaMJYWzveZS tXwW9pB6z5CdSy7jMtpD7OF2OofWCP3ZZU4XIkfqBUFXryM9OB083btx6asn3ygX l5FY1HG0RukhngCFOgrIer9SkAg0oJ89bL40NVOhXROV09MAdP3zGw/piojQXlyF TuaavqCKqLcHFUbw5yKvwFUkYRRECoAflob1Yi7pVKT9y9cXCQKnEB0Cwwv9QECL WWOKW3adPJ47HhoQYhJcVyyXAmP25J+k+WqBZxboY64ASIoj8HkVWHogOx917mDk nANm5q0ccaPI6yFvUkb0RKbtSbEChXM8ahiw7H6r79CKzh2GE5es+ZUVllAfmO/w Nz23w5aT43G8iYOmv42RSHgUOSxEQTGccumpWZPGABgEoubwXs4m/65TTl20NmRQ m/bVU0dDfiBIoVRuo1g4StM0wiW7ATh+ne/KJ0GR19qQ0DUsu9iC9+OeEF7Vko69 4Hp2Y0UVzjAniSAjVyK6nsWKlPQh88XeUWP5t/d7eD3KPEAWyv/yU65KhK33e+u/ MDHAuEfuOB5lBa9n8J3KMTdLb6yoQjudDnKRNhd8rxCX+UMq6wVxEO31nQnl2fll Y1yqj3eGdp1x2R9G0xC3 =qpKQ -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?511003B3.90600>