Re: [boost] Cmake

On Jun 24, 2017, at 1:53 PM, Robert Ramey via Boost wrote:

On 6/24/17 11:42 AM, Edward Diener via Boost wrote:

...

On 6/24/2017 1:05 PM, Peter Dimov via Boost wrote:

...

P F wrote:

...

https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo

The library for Boost.System is just:

bcm_boost_package(system VERSION 1.64 SOURCES src/error_code.cpp DEPENDS assert config core predef )

This certainly looks cleaner. It needs to distinguish between public and private dependencies but that's easy to fix. And of course there's the question who will maintain the version and the dependency list. Shouldn't this be generated on the fly ? The sources are all files in the library's 'src' subdirectory and the dependencies come from your own boostdep.

I don't see that this is possible. Consider and example:

a) I have and application A which uses the boost::date_time library. b) But it doesn't serialize dates/times So it doesn't include the date_time/serialization header c) So application is not dependent upon the serialization library d) And it doesn't have to include build / maintenance overhead that including the serialization library would entail.

Later

a) I make application B which used the boost::date_time library b) Part of the app also serializes date_time data c) So it includes date_time/serialization header d) And must be linked with the serialization compiled libraries.

My point is that one cannot support the notion of dependencies between libraries outside of the context of a particular application.

That’s what conditionals can be used for. That is, you would build with `-DBOOST_DATE_TIME_WITH_SERIALIZATION=1` to build with serialization. However, boost’s directory structure doesn’t support this well, as you would need multiple include directories for the different options. A simpler option would be to make a different module. That is if the user would like serialization support for date time, they can do `add_subdirectory(boost_date_time_serialization)` or `find_package(boost_date_time_serialization)`

So dependencies will either have to specified/maintained by hand or one will need a tool which does something like

dependencies A.cpp -> dependent libraries for application A dependencies B.cpp -> dependent libraries for application B

That will just make things much more complicated to interpret. This is a why a separate module is probably preferred over optional dependencies.