On 4/14/2016 5:51 PM, Paul Fultz II wrote:
On Thursday, April 14, 2016 at 4:18:07 PM UTC-5, Andrey Semashev wrote:
On 2016-04-14 22:00, Edward Diener wrote:
On 4/14/2016 1:37 PM, Rene Rivera wrote:
On Thu, Apr 14, 2016 at 12:33 PM, Louis Dionne
javascript:> wrote: Don't overthink it. All I'm saying is that the Boost guidelines recommend that CMakeLists.txt should appear in $some_library/build/CMakeLists.txt, while I argue that current practice is to put it in $some_library/CMakeLists.txt.
Just to be clear. It's not a recommendation. It's a requirement.
Ideally could not one have a CMakeLists.txt file wherever there is currently a jamfile ? In the library's 'build' directory to build a non-header only library, in the library's 'doc' directory to build the docs, in the library's 'test' directory to run the tests etc.
Yes, that is possible and what should be done according to the current guidelines. It's just not how it's typically done in other projects that use cmake.
The cmake files could be separated out to different directories, however there needs to be a top-level cmake to bring all of them together. This is because cmake is more of a configuration system rather than just a build system. So it can generate files for any build systems, Makefiles, Visual Studio. Technically, it could generate build files for boost, however, its not supported. So first you create and configure a build directory:
mkdir build cd build cmake ..
Then you can invoke the build through "targets". So if you want to build the tests you might build the 'check' target:
cmake --build . --target check
This is different than Boost.Build where you just cd into a directory and start building. This is why a top-level cmake file is important. The cmake file can be easily split across multiple cmake files if the library author wants, but there needs to be one at the top-level to glue them all together.
That's fair enough as long as one can "build" different parts of the library, with different options, separately.