Re: [boost] [CMake] what to do now?

14 Apr 2016

      On 4/14/16 12:00 PM, Edward Diener wrote:
...
On 4/14/2016 1:37 PM, Rene Rivera wrote:
...
On Thu, Apr 14, 2016 at 12:33 PM, Louis Dionne 
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.
I don't know CMake but I assume it must be capable of having multiple
CMakeLists.txt files for a library, or that a library's top-level
CMakeLists.txt can refer to the individual CMakeLists.txt files in order
to "build" all the library's components. If it is not capable of such
stuff it certainly isn't usable by Boost.
Actually I believe that that is the way CMake is generally used.

When I got CMake working I put it all in one file in order to replicate 
the pattern I'm used to with boost build.  Now I'm beginning to think 
this might have been a mistake.  I wondering if we shouldn't have used:

<library name>
   include
     *.hpp
   src
     *.cpp
     Jamfile.v2
     CMakelist.txt
   doc
     html
     boostbook
       CMakeList.txt to convert boost book to html
     quikbook
       CMakeList.txt to convert quikbook to html
     ...
   test
     Jamfile.v2
     CMakelist.txt
     *.cpp
     *.pp
   ...

Note that not all libraries would have all components. This has the 
appeal of being regular.
...
My personal problem with CMake is, while the language to use it is more
understandable for me than 'jam', its doc is just as hard for me to
understand as Boost Build if not even harder <g>. Mastering yet another
build system which is documented mainly for those who already know what
it is about is not my idea of programming fun.
This is the plague of "modern tools"  I spend more time 
working/configuring/etc the tools than I do actually writing source 
code.  It's a very depressing situation and no tool is immune.

Robert Ramey