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. 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 Robert Ramey