| 1 |
On Thu, Nov 03, 2005 at 08:30:26PM +0100, Thomas de Grenier de Latour wrote: |
| 2 |
> On Fri, 4 Nov 2005 01:19:35 +0900 |
| 3 |
> Jason Stubbs <jstubbs@g.o> wrote: |
| 4 |
> |
| 5 |
> > package.env would be a list of "<atom> <file> [<file> ...]" |
| 6 |
> ... |
| 7 |
> > With a couple of small modifications to emerge to check FEATURES |
| 8 |
> > for "buildpkg" after the call to setcpv() is done rather than |
| 9 |
> > doing it once globally, this would also cover TGL's BUILD_PKGS |
| 10 |
> > addition too. |
| 11 |
> |
| 12 |
> Since being able to list several env file on a same line doesn't |
| 13 |
> sounds like a must have feature to me, i would much prefer a |
| 14 |
> package.env format of that kind: |
| 15 |
> <rule> [<rule> ...] <envfile> |
| 16 |
> where <rule> would be similar to what i've defined for BUILD_PKGS |
| 17 |
> (with addition of full versioned dep atoms, which is a trivial |
| 18 |
> change to my code). And if a package happens to match the rules |
| 19 |
> lists of several lines, then the corresponding env files would all |
| 20 |
> be sourced, in the order of the said lines. I can try to implement |
| 21 |
> that if you agree on the idea. |
| 22 |
|
| 23 |
Offhand, why isn't this a bashrc trick? |
| 24 |
|
| 25 |
Via bashrc env modification you've got a helluva lot more flexibility, |
| 26 |
ability to set vars dependant on returns of funcs, etc. |
| 27 |
|
| 28 |
> My second concern is about unsupported variables (some of the |
| 29 |
> FEATURES flags, some of the *DIR locations, etc.): i think they |
| 30 |
> should be somehow blacklisted, to avoid crazy breakages/bugreports |
| 31 |
> (btw, a quick look on the variables listed in make.conf.example |
| 32 |
> made me realize it was not that easy to write an accurate |
| 33 |
> blacklist, which tends to confirm it's really needed). |
| 34 |
|
| 35 |
This also weighs in as to why this is needed when bashrc can |
| 36 |
accomplish it just as well. |
| 37 |
~harring |
Archives