[Home]Environment Variables

BOOST WIKI | RecentChanges | Preferences | Page List | Links List

What Conventions are needed for protecting environment variables?


Toon:

The global namespace (for env. vars) is already too polluted and clashes of environment variables are impossible to deal with.

Dave:

Right. So the question is: how much of a problem does that create for Boost.Build? AFAICT, the biggest danger is that it might pick up symbol definitions which weren't intended for it, since it doesn't automatically add definitions to the environment. Can't most of that problem be counteracted with a site-config.jam file where explicit settings are made? I suppose that as the number of externally-loaded variables grows, it could get to be more and more of a problem.

Toon:

It might not be a problem for Boost but it might be a problem for other tools.

Dave:

I understand... but we can circumvent that problem by recommending that people put Boost.Build-specific settings in their site-config.jam file instead of sticking them in the environment. n Take a look at the plethora of global variables used in the Jambase which are set with ?=, so they can be overridden on the command-line or in the environment (or, in my scheme, in a site-config.jam). Don't you think it would get unweildly prefix each one with "BOOST_"?

or, better yet, perhaps there's an option which imports all environment variables into a built-in module called "environment" instead of into the global module?

Toon:

Next, IMO it's just pure logic that one would also use/simulate namespace for environment variables.

Dave:

Somebody once said that "proof by analogy is fraud" ;-), but anyway, I have no problem with the idea of namespacing in principle; I'd just think I'd like to see something cleaner than using a BOOST_... prefix everywhere.

Toon:

If you feel no problems should occur when not prefixing env.vars, if you find it too much typing, no problem for me : we'll see if we'll have some clash later on

Dave:

Maybe it's not such a big deal after all; when Boost.Build is in use, I think most of the global variable settings inherited from Perfore Jam's Jambase will not be used, so we can afford to use BOOST_ on the few things we need.


BOOST WIKI | RecentChanges | Preferences | Page List | Links List
Edit text of this page | View other revisions
Last edited November 17, 2004 5:45 pm (diff)
Search:
Disclaimer: This site not officially maintained by Boost Developers