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

Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-08-03 20:47:52

AMDG

On 08/03/2017 02:11 PM, Stefan Seefeld via Boost-build wrote:
> 
> 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)

 I'm not quite sure what you mean by a generator rule.
generators are based on target type.  So with C as
a typed-target{EXE}, we get:

construct EXE from CPP:
  - composing generator gcc.link OBJ -> EXE
   (required properties <toolset>gcc-7.1.1) is viable
    - Need OBJ, trying to construct OBJ from CPP
      gcc.compile.c++ is viable

> * 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.)
> 

  It's no quite correct to say that C is an alias for
C.exe.  There are actually three levels of targets.
- A main target (such as C) is what is defined in the Jamfile
- A virtual target is an intermediate layer representing
  a specific file.  There can be multiple virtual targets
  for the same file as long as only one is actualized.
  (This mainly exists to allow backtracking in generators.
  Unlike a Jam target, creating a virtual-target doesn't
  affect global state, so it's safe to create and discard
  virtual-targets.)
- A Jam target is the thing that gets passed to the
  build engine for processing.

main-target.construct(properties) returns a list of virtual targets.
virtual-target.actualize() returns a Jam target.

In Christ,
Steven Watanabe