Re: [boost] Fwd: Installing CMake configuration files

Subject: Re: [boost] Fwd: Installing CMake configuration files
From: Peter Dimov (pdimov_at_[hidden])
Date: 2018-10-19 22:52:42

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

BOOST_ROOT = [ modules.binding $(__name__) ] ;
BOOST_ROOT = $(BOOST_ROOT:D) ;

which kind of implies that it relies on getting the absolute path.

>   * That just leaves the stage directory, which is tied to the
>     project root, and should perhaps be calculated in Jamroot
>     instead of in boost_install.

The stage directory needs to be retrieved from boostcpp, but boostcpp just 
sets it to "stage", which only works from top-level. It should probably use 
$(BOOST_ROOT)/stage, and then other modules can peek for it.

There are other things that are needlessly replicated - 
install-header-subdir, install-default-prefix. All of these need to be 
peekable from a canonical location.

> * This seems to handle --layout=versioned, but I'm not clear on
>   how well it handles --layout=system where we expect to use a
>   single compiled library for all configurations.

It worked when I tried it. Note that you can have two libraries 
with --layout=system, not just one; libfoo.a and foo.so.

> * Are the error messages that you get from CMake when there
>   isn't a configuration that matches the request intelligible?

Not very. There's Boost_DEBUG, which tells you why something was skipped, 
but ideally, it needs to detect the case when no variant matched, and _then_ 
tell you why things were skipped without your having to set Boost_DEBUG 
beforehand. I haven't gotten that far yet; usability can be improved once we 
have it working.

>   It looks like the target will exist but will silently do nothing?

Yes, you get a link error.

>   What if something goes wrong and there are multiple matches?

I haven't encountered this so far :-) although it's possible in principle 
because at the moment I ignore some "non salient" properties.

> * 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. :-)