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