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