Re: [boost] Fwd: Installing CMake configuration files

Subject: Re: [boost] Fwd: Installing CMake configuration files
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-10-20 00:10:57

AMDG

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.
> 
>> <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
([ 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
usage-requirements.

In Christ,
Steven Watanabe