[oe] AAAARGH! openembedded..... pcmciautils. SOLVED!

[Richard Purdie]

On Sat, 2007-12-15 at 17:55 +0200, Paul Sokolovsky wrote:
> Thought about this too:
>    
> >> any good reason OE doesn't entirely clear ALL
> >> environment variables from the user EXCEPT ones known to be desirable on build
> >> so you have a clean and fresh environment that is known and fixed?

Bitbake reads all variables from the environment into its variable space
when run. Any variable loaded from the original environment are marked
as an export so it gets passed to executed tasks. More recently we added
an "unexport" flag so you could actually stop it from doing this in
cases known to cause problems (e.g. MACHINE). This is a long established
behaviour of bitbake and changing it would probably break the way people
use bitbake and break backwards compatibility.

Loading variables from the environment is a really useful feature which
I personally, Poky and I suspect others make heavy use of. It implies
you should have a relatively clean environment and perhaps that needs to
be more predominately documented.

Exporting those variables makes things more visible. Even if not
exported, we would still have potentially weird build failures for users
with dirty environments since it does affect the variable space quite
significantly.

So yes, bitbake could stop exporting all variables but it would just
hide more subtle problems rather than solving them.

In some cases we need to unexport. In the MACHINE case, setting from the
environment is useful but we need to stop it getting passed to the task
environment as it breaks things like binutils. In general I'd prefer the
bitbake environment init scripts sanity check or clean the environment
or something like sanity.bbclass could check for known bad exports and
error asking the user to fix their environment rather than just blindly
adding to the list of unexports...

Cheers,

Richard