Boost logo

Boost :

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__) ] ;
> which kind of implies that it relies on getting the absolute path.
>> <snip>
>> * 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
([ ] = 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 [ [ $(t).type ] IMPORT_LIB ]
      return $(t) ;
    else if [ [ $(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

In Christ,
Steven Watanabe

Boost list run by bdawes at, gregod at, cpdaniel at, john at