b2 generation of boundnames

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

b2 generation of boundnames

Boost - Build mailing list

Hi Steven, all,

I have just noticed an issue in Faber, and I'm wondering how you solved this in b2:

A target (bound) filename is generated using the target properties / features (I never quite figured out the nomenclature you use), at least the non-incidental ones. So, part of a library's filename will be a subdirectory path encoding whether the library is shared or static. Fine so far. Now consider two object files, `lib.o`, being an intermediate file that's being linked (or archived) into the library. The other, `main.o`, being an intermediate file being compiled into an executable, which is *linked* with the library.

How are the bound filenames of those object files computed, and in particular, what properties / features are participating, to make the filenames unambiguous ?

While I can see how the (essential) properties of a library percolate to the constituent object files, and thus, generating the proper `.../shared/lib.o` and `.../static/lib.o` filenames. But I'm unsure about how to do that properly with `main.o`: What if it links to two libraries, one static, the other shared ? It seems quite hard to come up with a clear rule as to how to generate the filename in that case. How do you do that in b2 ?

Thanks,


Stefan
-- 

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

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

Re: b2 generation of boundnames

Boost - Build mailing list
AMDG

On 12/19/2018 07:30 PM, Stefan Seefeld wrote:
> I have just noticed an issue in Faber, and I'm wondering how you solved
> this in b2:
>
> A target (bound) filename is generated using the target properties /
> features (I never quite figured out the nomenclature you use),

<link> is a feature.  <link>shared is a property.

> at least
> the non-incidental ones. So, part of a library's filename will be a
> subdirectory path encoding whether the library is shared or static. Fine
> so far. Now consider two object files, `lib.o`, being an intermediate
> file that's being linked (or archived) into the library. The other,
> `main.o`, being an intermediate file being compiled into an executable,
> which is *linked* with the library.
>
> How are the bound filenames of those object files computed, and in
> particular, what properties / features are participating, to make the
> filenames unambiguous ?
>
> While I can see how the (essential) properties of a library percolate to
> the constituent object files, and thus, generating the proper
> `.../shared/lib.o` and `.../static/lib.o` filenames. But I'm unsure
> about how to do that properly with `main.o`: What if it links to two
> libraries, one static, the other shared ? It seems quite hard to come up
> with a clear rule as to how to generate the filename in that case. How
> do you do that in b2 ?
>

Boost.Build works the other way around.
That is, <link>shared propagates from the
executable to the library, not from the
library to the executable.  The only way
to link to both a static and a shared library
is if one of the libraries explicitly overrides
the value of <link> that it receives.

Example:

Jamroot:
lib static : static.cpp : <link>static ;
lib shared : shared.cpp : <link>shared ;
exe main : main.cpp static shared ;

$ b2 link=static # builds link-static/main.o
$ b2 link=shared # builds link-shared/main.o

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: b2 generation of boundnames

Boost - Build mailing list
On 2018-12-19 22:05, Steven Watanabe via Boost-build wrote:

Boost.Build works the other way around.
That is, <link>shared propagates from the
executable to the library, not from the
library to the executable.  The only way
to link to both a static and a shared library
is if one of the libraries explicitly overrides
the value of <link> that it receives.

Example:

Jamroot:
lib static : static.cpp : <link>static ;
lib shared : shared.cpp : <link>shared ;
exe main : main.cpp static shared ;

$ b2 link=static # builds link-static/main.o
$ b2 link=shared # builds link-shared/main.o

Ah, so had the two libraries `static` and `shared` not explicit `link` properties, they would both be compiled as `shared` and `static` libs respectively in the two invocations ?

Thanks,

Stefan
-- 

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

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

Re: b2 generation of boundnames

Boost - Build mailing list
AMDG

On 12/19/2018 08:43 PM, Stefan Seefeld via Boost-build wrote:

> <snip>
>> Jamroot:
>> lib static : static.cpp : <link>static ;
>> lib shared : shared.cpp : <link>shared ;
>> exe main : main.cpp static shared ;
>>
>> $ b2 link=static # builds link-static/main.o
>> $ b2 link=shared # builds link-shared/main.o
>
> Ah, so had the two libraries `static` and `shared` not explicit `link`
> properties, they would both be compiled as `shared` and `static` libs
> respectively in the two invocations ?
>

Exactly.

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: b2 generation of boundnames

Boost - Build mailing list
On 2018-12-19 22:47, Steven Watanabe via Boost-build wrote:
AMDG

On 12/19/2018 08:43 PM, Stefan Seefeld via Boost-build wrote:
<snip>
Jamroot:
lib static : static.cpp : <link>static ;
lib shared : shared.cpp : <link>shared ;
exe main : main.cpp static shared ;

$ b2 link=static # builds link-static/main.o
$ b2 link=shared # builds link-shared/main.o
Ah, so had the two libraries `static` and `shared` not explicit `link`
properties, they would both be compiled as `shared` and `static` libs
respectively in the two invocations ?

Exactly.

Thanks, that makes sense !

Stefan
-- 

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

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