Subject: Re: [boost] [CMake] what to do now?
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-04-14 18:14:15
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 <ldio..._at_[hidden]
>> <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.