Re: [Boost-build] prototyping alternative Boost.Build syntax

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:
> AMDG
>
> 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
>>> http://www.boost.org/build/doc/html/jam/language.html#jam.language.modules
>> 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 ?

Thanks,
        Stefan

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