Boost logo

Boost-Build :

Subject: Re: [Boost-build] prototyping alternative Boost.Build syntax
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-11-07 11:45:36

On 07.11.2016 10:34, Steven Watanabe wrote:
> On 11/06/2016 11:07 PM, Stefan Seefeld wrote:
>> On 04.11.2016 11:18, Steven Watanabe wrote:
>>> On 11/04/2016 07:29 AM, Stefan Seefeld wrote:
>>>> * what is a "module" and how is it used in the engine ?
>>> See modules.h. Also
>> Thanks. I have been reading that document, and am a little confused as
>> it seems the rules are slightly inconsistent, so I wonder whether I have
>> merely misunderstood...
>> The document explains how rules defined in one module can be accessed
>> (by qname) from within another. But it seems that concept (of qualified
>> naming) doesn't apply to anything else, such as action, variable, or
>> target names. Am I reading that right ? And if so, why is that so ?
> Modules are a bit of a hack for historical
> reasons. In practice it isn't much of a problem.
> - Actions and rules are accessed in the same way.
> Thus, actions can be called from other modules.

Ah, that's good. I was wondering how to avoid naming collisions for
user-defined actions...

> - Targets refer to the file system which is
> global. Scoping them by module would be
> counterproductive.

OK. And for the 'notfile' targets ('clean', 'all', 'test', etc.) I can
synthesize names based on the build script filename they are defined in.

> - Most variables shouldn't be accessed from
> other modules anyway.

Here I'm not sure. I was wondering about large projects with multiple
Jamfiles, where sub-project Jamfiles would inherit variables from
'outer' scopes (but could modify them locally). How does Boost.Build now
handle this ? Is it using target-specific variables in most cases ?


      ...ich hab' noch einen Koffer in Berlin...

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at