Subject: Re: [Boost-build] b2 generation of boundnames
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-12-20 03:05:15
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.
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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk