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

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-04-05 23:56:47

On 2002-04-04 at 01:59 AM, david.abrahams_at_[hidden] (David Abrahams) wrote:

>
>----- Original Message -----
>From: "Vladimir Prus" <ghost_at_[hidden]>
>
>> David Abrahams wrote:
>>
>> The question is what we do about it. There are two issues:
>>
>> 1. Both Rene's initialization code and my project.jam do some
>crawl-up. Since
>> crawl-up is needed in initialization anyway, I don't mind using Rene's
>code.
>> Besides, it gives more reasonable error messages.
>
>Good plan.

I put special effort into those initial error messages, I still remember the
initial frustration in figuring out how to setup boost.build ;-) Just wanted
to make it easier on future users.

>> 2. All jamfiles in one module or all jamfiles in separate modules.
>This is a
>> big question -- I always thought that module-per-jamfile is better,
>largely
>> because of similarity of this approach to object-oriented programming.
>
>When in doubt, I prefer separation of namespaces.

I also prefer Jamfiles being in separate spaces.

>> In
>> fact, there more than one variable that describe a project and so
>making each
>> Jamfile a module seems reasonable, while the only drawback is using
>variables
>> defined in project root.
>
>I hope that users won't do much communication via variables. However,
>see Steve K's posting on variable exporting. I think it might make sense
>to have something similar. I favor a style of exporting which makes
>variables visible in everything lower down in the (sub)project
>hierarchy. Finally, I think we shouldn't implement this until there is a
>demonstrated need.

I still see C++ namespace type scoping as the ideal. Myself I set a good
number of variables in my project-root. They are not used for communication,
they are set to the various locations in my CVS hierarchy so that I can
easily refer to them in the Jamfiles. So if it becomes hard to something
that is utterly simple now, sepcifically <sysinclude>$(SOMELOCATION), I
think we've gone backwards in the translation from V1 to V2.

But then again maybe better use of things like variant and template will
reduce my need to do that. Or at least reduce the places where I directly
use variables.

Hmmm, now that I keep thinking about I'm reminded about one of the
constructs we have which we barely use, "path-global". Having something like
that but for project variables would solve this quandry. Having a
"project.global" declaration would allow us to have it both ways. Having
such a list would let us automatically make those variables available to the
Jamfile modules.

OK, so here is my suggestion:

1. Do individual modules per Jamfile.
2. Do individual modules per project-root file.
3. Have a "project-global" declaration whose variables are automatically
made available in the Jamfile modules.

>> Frankly, I never realized we have this problem. But:
>> 1. It probably not very important. First, we'll inherit includes from
>parent
>> project (and from project root, maybe?)
>> 2. I believe (and I think we've talked about it some time ago), that
>backward
>> propagation of requirement should be supported. E.g. -- a using
><lib>boost in
>> sources will automatically add boost includes.
>
>Agreed.

No. Doing that generically would be a problem for me. If we make that the
default behaviour I would need a way to prevent those and other kinds of
properties from propagating to other targets. It might not be evident to
Boost compiling, after all Boost does the sensible thing of having a
separate include directory. But I make use of other packages which aren't
that sensible. I have to deal with some projects which have different
settings, and includes for when building the lib, than when using the lib.

Another discrepancy I'd like to bring up between Valdimir's code and mine is
the location of where we do the loading of
modules/Jamfiles/porject-roots/etc. I initially modified the modules.load
with the goal of keeping the management of loading in one place. But Dave
pointed out some drawbacks to changing modules.load, which I agree with, it
does make it more convoluted and prone to bugs. But I don't agree on having
multiple load routines that all do basically the same thing, that's even
more prone to bugs. So that boils it down to needing another module that
does the file load management. Would a "file" module be apporpriate for
this. And is there more functionality other than load that can become part
of that? (one I can think of right now is "file.glob").

PS. Last Sunday I put a preliminary version of the doc system I mentioned.
If you guys get a chance could you take a look at it. Getting comments on it
soon would cool, as opposed to later when it's harder to change :-)

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]