Subject: Re: [boost] Fwd: Installing CMake configuration files
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-10-20 00:10:57
On 10/19/2018 04:52 PM, Peter Dimov via Boost wrote:
> Steven Watanabe wrote:
>> Just a couple comments:
>> * I'm not fond of the ROOT parameter for boost-install.boost-install.
>> Â * Dependencies can be referenced with /boost/$(deps)//[stage|install]
>> Â * You can find the full path to the boost-install.jam with
>> Â Â Â [ path.root [ modules.binding $(__name__) ] [ path.pwd ] ]
>> Â Â Â This avoids hard-coding the location of boost_install relative
>> Â Â Â to the superproject.
> Actually, [ modules.binding $(__name__) ] seems to return an absolute
> path, so path.root/path.pwd may not be needed here? boostcpp.jam does
I looked it up, and you are correct: modules.binding
always returns an absolute path, provided that the module
is loaded with `import` and not the lower level `modules.load`.
> BOOST_ROOT = [ modules.binding $(__name__) ] ;
> BOOST_ROOT = $(BOOST_ROOT:D) ;
> which kind of implies that it relies on getting the absolute path.
>> * If generate-cmake-config takes the library as a source,
>> Â then it's possible to derive both the library dependencies
>> Â and the exact library name from the library target.Â The
>> Â dependencies can be found at the virtual target level in
>> Â generate-cmake-config, and the exact file name will appear
>> Â as the source in generate-cmake-config-.Â Doing it this way
>> Â also has the side effect that the CMake configuration won't
>> Â be installed if the library fails to build, which may be a
>> Â good thing.
> These may take me a while to figure out. :-)
Getting the library name this way isn't too bad.
Just pass it through all the generate/action logic
and then in `generate-cmake-variant-` say:
local fname = $(sources:BS) ;
The logic for choosing static/shared/import lib
is really annoying actually. The test you have
([ os.name ] = NT) is definitely wrong, as it should
be based on the target-os. Also cygwin needs import
libs (IIRC, cygwin can link directly to a dll, but
there are a few corner cases that don't work right.).
# Process virtual targets containing a LIB
# target. IMPORT_LIBs take priority if both a
# SHARED_LIB and an IMPORT_LIB are present.
# Note: There might be other random files like *.pdb,
# which are ignored. Call this in generate-cmake-variant
# to filter the sources to pass to the action.
local rule .choose-lib-target ( sources * )
local result ;
for local t in $(sources)
if [ type.is-derived [ $(t).type ] IMPORT_LIB ]
return $(t) ;
else if [ type.is-derived [ $(t).type ] LIB ]
result = $(t) ;
return $(result) ;
Automating the dependencies is harder, but I would
also give it lower priority (since you've already
scripted it, it's less of a problem when it gets
out of sync). I think that to make it work, you'll
need to put it into *-variant.cmake file, since
it would need to be extracted from a specific
library build. For static libraries, you can
just look at the <library> property, since
the dependencies will be propagated upwards as
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk