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