Subject: Re: [boost] Cmake
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-06-24 21:15:49
On 6/24/17 1:18 PM, Edward Diener via Boost wrote:
> On 6/24/2017 2:53 PM, Robert Ramey via Boost wrote:
>> On 6/24/17 11:42 AM, Edward Diener via Boost wrote:
>> dependencies A.cpp -> dependent libraries for application A
>> dependencies B.cpp -> dependent libraries for application B
> How is a library supposed to know what your application needs
Right it can't. That is my point.
One cannot say that the date/time library dependent upon the
serialization library just because it includes some of the serialization
library headers. You can't say that any time the date/time is used the
serialization library has to be included as well. You have to wait
until you see the final application to know whether the part of
date/time you actually used includes the serialization library.
There seems to be an idea that one can build library dependencies
automatically by recurrsively scanning the source code #include files.
This examples shows why this cannot be done. Dependency outside of a
particular application is undefined.
? That is not its responsibility. Doesn't CMake allow manipulation of
> application needs at some higher level ? When I have used CMake to build
> LLVM/Clang it certainly allowed me to choose what I wanted for my
> particular build even though LLVM/CLang provide a whole slew of
> CMakeLists.txt files.
If we cannot setup CMake pretty easily for Boost
> libraries so that the end-user can manipulate builds and tests for his
> needs our CMake setup will be worthless.
LOL - I'm sure we can do it manually. That's what I do. What we can't
do is build date/time ahead of time before we know the application.
This topic originally came up in the discussion of boost tools bcm?
which automatically build a dependency tree.