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.

Attachment: pgphlYBUpn8kH.pgp
Description: PGP signature

Reply via email to