Re: [boost] Cmake

Subject: Re: [boost] Cmake
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-06-24 18:53:09

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