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

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-04-06 01:41:59

On 2002-04-06 at 12:34 AM, david.abrahams_at_[hidden] (David Abrahams) wrote:

>----- Original Message -----
>From: "Rene Rivera" <grafik666_at_[hidden]>
>
>> 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.
>
>We can easily automatically export the bindings, but of course we cannot
>easily make them look like variables. In other words, we can make this
>work with the proviso that the user doesn't try to modify the variable
>in a subproject.

Yes, not modifying them is what I had in mind. After all if you'r modifying
them, then you are most likely using them for communications between
Jamfiles. And that's something we would want to avoid. What I had in mind
was copying them into the Jamfile module, which has the advantage of
preventing sideffects from Jamfile to Jamfile.

>> 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.
>
>Agreed, unless one load routine calls the other. There's nothing at all
>wrong with re-using the name "load". I confess to not having analyzed
>Vladimir's "load" code at all. Can someone summarize what it's doing
>that's different from modules.load?

Vladimirs code also calls modules.load, but because it doesn't have to
dictate the tag used to indicate that the jamfile was loaded it doesn't need
changes to modules.load. In fact I just realized this is a moot point, I
keep forgetting this. If we have one module per Jamfile, the changes that I
did to modules.load are not needed! Yeay :)

>> So that boils it down to needing another module that
>> does the file load management. Would a "file" module be apporpriate
>for
>> this.
>
>It depends whether we need it.

Given what I just said above, I guess we don't need it.

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