> Thanks. So to be perfectly clear: 'l' isn't known to the engine, which
> implies that any target name I use on the command-line is never passed
> directly to the engine (e.g. using `bjam.update()`, with the Python
> frontend), but is looked up in the b2 logic and translated to a
> registered target name that is known by the engine. Right ?

 

That is correct.

> And a related question: where is the path schema defined that generates
> a file name including different features (such as
> 'bin/gcc-6.3.1/debug/libl.so') ? And how is that schema chosen by a
> given target ? Is it used by all targets, whether the given features
> affect the target build or not ?

 

Each metatarget takes the given build request* and constructs virtual targets.

Virtual targets are targets that are to be built and contain property sets on them.

To construct the path to the target, a combination of the location of where the

metatarget was declared and the features within the property set are used.

The location of the metatarget is already a path, but the property set needs

to first be converted to a path. This is done using the as-path() rule in property.jam.

 

The path is generated when the virtual target is actualized. See the actual-name()

method on the abstract-file-target class in virtual-target.jam

 

* a build request is all of the properties and targets passed on the command line

that are mixed with all of the default properties (non-optional features). This

build request is applied to every metatarget to construct a virtual-target which

is then actualized to a low-level engine target.

 

Aaron