target naming

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

target naming

Stefan Seefeld-2
With a Jamfile as simple as:


  lib l : l.cpp : <link>shared ;
  exe hello : hello.cpp l ;

I can refer to the defined targets using different names (e.g., 'l',
'libl.so', 'bin/gcc-6.3.1/debug/libl.so'). Where are these aliases
defined ? Are they all registered to the engine (backend) ? Or is the
translation handled inside the Jamfile logic ?

Using the --debug-building option, I get output such as

     Building target './l'
     ...

    Usage requirements for l:


However, './l' isn't a known target, i.e. calling `bjam ./l` yields an
error.
What are the exact rules by which targets are named ?

Thanks,
        Stefan

--

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: target naming

Aaron Boman
The "l" target is a metatarget and only exists within the Jam logic. In order to build it, if you're in the same directory as the build.jam that declares it, then you can simply specify its name:
 
bjam l
 
If you're going to specify the directory where the target is declared, you must use the target reference syntax: [directory of a build.jam]//[target name]. In this case, to build "l" specifying the directory, the command would look like this:
 
bjam .//l
 
The other two targets are the actualized virtual target names, a.k.a. low-level Jam engine targets. They are declared to the engine during the actualization phase in the virtual-target module:
 
DEPENDS $(target:G=e) : $(target) ;
DEPENDS $(target:G=e:R=$(path)) : $(target) ;
 
An <e> grist is used to denote both of these targets.
 
Aaron
--------- Original Message ---------
Subject: [Boost-build] target naming
From: "Stefan Seefeld" <[hidden email]>
Date: 1/20/17 9:16 am
To: "Boost.Build developer's and user's list" <[hidden email]>

With a Jamfile as simple as:


lib l : l.cpp : <link>shared ;
exe hello : hello.cpp l ;

I can refer to the defined targets using different names (e.g., 'l',
'libl.so', 'bin/gcc-6.3.1/debug/libl.so'). Where are these aliases
defined ? Are they all registered to the engine (backend) ? Or is the
translation handled inside the Jamfile logic ?

Using the --debug-building option, I get output such as

Building target './l'
...

Usage requirements for l:


However, './l' isn't a known target, i.e. calling `bjam ./l` yields an
error.
What are the exact rules by which targets are named ?

Thanks,
Stefan

--

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: target naming

Stefan Seefeld-2
Hi Aaron,

thanks for the quick reply.

On 20.01.2017 10:31, [hidden email] wrote:

> The "l" target is a metatarget and only exists within the Jam logic.
> In order to build it, if you're in the same directory as the build.jam
> that declares it, then you can simply specify its name:
>  
> bjam l
>  
> If you're going to specify the directory where the target is declared,
> you must use the target reference syntax: [directory of a
> build.jam]//[target name]. In this case, to build "l" specifying the
> directory, the command would look like this:
>  
> bjam .//l
>  
> The other two targets are the actualized virtual target names, a.k.a.
> low-level Jam engine targets. They are declared to the engine during
> the actualization phase in the virtual-target module:
>  
> DEPENDS $(target:G=e) : $(target) ;
> DEPENDS $(target:G=e:R=$(path)) : $(target) ;
>  
> An <e> grist is used to denote both of these targets.

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 ? (The reason
I ask is that in my own experimentation I'm using 'alias' to declare all
possible mappings, and I wonder what names I need to register as aliases
for command-line target names to be recognized by the engine directly.

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 ?

Thanks,
        Stefan



--

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: target naming

Aaron Boman
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build