Re: [Boost-build] feature, properties, variants, and all the rest

Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-08-03 20:11:42

On 03.08.2017 15:55, Steven Watanabe via Boost-build wrote:
> AMDG
>
> On 08/03/2017 01:14 PM, Stefan Seefeld via Boost-build wrote:
>> On 01.08.2017 22:41, Steven Watanabe via Boost-build wrote:
>>> On 08/01/2017 08:24 PM, Stefan Seefeld via Boost-build wrote:
>>>> On 29.07.2017 11:24, Steven Watanabe via Boost-build wrote:
>>>>> obj A : a.cpp : : <include>/a/path ;
>>>>> obj B : b.cpp : [ check-target-builds A : <use>A ] ;
>>>>> exe C : C.cpp : [ check-target-builds B : <use>B ]
>>>>>
>>>>> Now, when building C, it will go something like this:
>>>>> - Building C
>>>>>   - Building B from check-target-builds
>>>>>     - Building A from check-target builds
>>>>>       - A builds successfully
>>>>> <snip>
>> OK, I see. Thinking this through a little, I run into some circular
>> dependency, though, so I wonder how you solve this:
>> The user declares target 'C'. Once it is built, it uses a "bound name"
>> corresponding to the actual file being generated. However, that bound
>> name can only be found in the process of building the dependency graph
>> (specifically, by identifying the tool used to build it). So, how can
>> you establish the "outline" of the dependency graph with 'C' being the
>> final target, when it doesn't even have a name yet ?
>>
>   I used indentation to indicate the sub-steps required.
> "Building C" is not actually completed until the very
> end.

Yes, figured. Can you draw out the dependency graph in more detail (or
just the bits involved in making 'C') ? If I request `b2 C`, what are
the steps involved, leading up to some file
"bin/gcc-7.1.1/release/.../C.exe" being generated ? I expect something
like this:

* C is declared in the Jamfile, as being depend on C-gen (a generator
rule that will actually instantiate some further dependency graph for C)
* Thus, after reading the Jamfile, b2 does this:

- considering C (to be built from C.cpp)
  - building C-gen (as C's "static" prerequisite)
      * this will determine g++-7.1.1 as the tool to build C.exe from
C.cpp via C.o
      * thus, C.exe is injected as a new prerequisite target for C, C.o
as dependency for C.exe
  - building C.o from C.cpp
  - building C.exe from C.o
- building C (nothing left to do, it's just an alias for C.exe)

Does this make sense, and more importantly, does it capture the logic in
b2 ? (By "Static prerequisite" above I'm referring to the fact that the
dependency from C to C-gen needs to be known before the engine is
started, as otherwise it wouldn't find any prerequisites for C at all,
and thus just make nothing in order for C to be considered up-to-date.)

Thanks,
        Stefan

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