Boost logo

Boost :

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


AMDG

On 10/19/2018 06:29 PM, Peter Dimov via Boost wrote:
> Steven Watanabe wrote:
>
>> Automating the dependencies is harder,
>
> That's what I thought. :-)
>

  It turns out to be easier than I originally
anticipated. Before we go there, however, I'd
like to discuss whether it's actually the right
thing to do. In particular, I don't want to go
down a path that will get in the way of modular
installation for headers.

# Ideally it should look something like this:
link-directory headers : ../include
  : requirements <location>$(BOOST_ROOT)
  : usage-requirements <include>$(BOOST_ROOT) ;
alias boost_any : headers /boost/config//boost_config ;
boost-install boost_any ;

A few issues that are going to come up:
- The stage target needs a hard dependency on the headers.
  The default behavior for link-directory is to let the
  #include scanner trace the headers to stage.
- The install target will need to introspect the headers
  target to find the files to copy.
- For the generated cmake files, distinguishing between
  the headers of the current library (which should be
  represented directly) and the headers of some other
  library (which should be represented as a dependency)
  is a bit of a pain. Comparing the project of a headers
  target with the project of the current install target
  will work I think.
- The dependencies found will probably end up being the
  transitive closure of all dependencies unless we take
  extra measures to reduce them. This isn't technically
  wrong, but may result in excessively long lists.
- We have to assume that the library targets are defined
  in the same project that has the stage/install targets.
  For instance, putting the actual library targets
  in a subproject and making an alias in build/Jamfile
  will break badly. This is probably the biggest issue
  I have, as I think that implicit behavior based on
  targets being in the same project is unintuitive and
  potentially surprising.

In Christ,
Steven Watanabe


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk