Re: [jamboost] Boost.Build V2, load behaviour part 2.

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-31 13:15:51

----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>
To: <jamboost_at_[hidden]>
Sent: Sunday, March 31, 2002 12:42 PM
Subject: Re: [jamboost] Boost.Build V2, load behaviour part 2.

> On 2002-03-31 at 12:03 PM, david.abrahams_at_[hidden] (David Abrahams)
wrote:
>
> >> To be specific, I need to call load to load the Jamfiles, but they
> >need to be
> >> in the module of the project-root...
> >
> >Do they? What are the negative implications of doing otherwise? One
> >thing I see, which I rather like, is that even in large projects each
> >subproject would have its own variable namespace.
>
> Yes they do, at least I think so, so correct me if it's not this
way... Given
> this:
>
> module project-root {
> # in project-root.jam...
> MY_INCLUDES = /usr/local/include ;
> #
> }
> module jamfile-module {
> # in .../Jamfile
> exe point : point.cpp : <sysinclude>$(MY_INCLUDES) ;
> #
> }
>
> Has unexpected results, you'll get nothing for the MY_INCLUDES var in
the
> Jamfile.

You're correct.

> Unless there is a way to import all the project-root vars into the
> jamfile-module, I don't see any other way than to put the jamfile in
the
> project-root module.

We could make a builtin that enumerates the names of all variables in a
module so we can poke all the values from the project-root into the
jamfiles. They would then be separate copies... OK, I am provisionally
convinced that you made the right design choice. As long as we give
people a way to make their own modules with true namespace protection
(and we have done that), I think you're right that all
projects/subprojects should share variables and rules.

[Steve K., I'd appreciate hearing from you about this - how does Scons
deal with variable/function scoping in large, multi-sconsfile
projects?... oh, its the environment which carries this info across
Sconsfiles, right?]

> >Naw, tag is fine, but it has nothing to do with the module. It is a
file
> >identifier. Why don't you just derive that directly from the file
(with
> >perhaps a little path normalization/simplification?)
>
> True, it's a file ident in this case, but it doesn't have to be that
in other
> cases.

explain, please?

> We could use the <some-jamfile-dir> as the ident, but that would
change
> the meaning of the "search" argument for everybody else. At that point
having
> a different "load" specifically for jamfiles is preferable. But then
we have
> two different places to maintain the load code :-(

I'm still in the dark. Don't you want to use the full path to the file,
including its name, as the identifier?

> Of course, if the import question is resolvable, this becomes a moot
point :-)

"the import question?"

> >> :-) ... but you can't handle --help* with HD* ;-\
> >
> >Why not?
> >You just need to write an action which dumps the help, right?
>
> Because they are considered options by the Jam executable. Which means
that
> they are not passed along as targets. Or maybe you mean to check the
args and
> insert fake targets to do the help?

The latter.

-D