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

Subject: Re: [boost] [CMake] what to do now?
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-04-15 20:00:59

On 4/15/16 3:45 PM, Paul Fultz II wrote:
>
>
> On Friday, April 15, 2016 at 1:33:10 PM UTC-5, Robert Ramey wrote:
>>
>> On 4/15/16 10:13 AM, Paul Fultz II wrote:

>> If I want to just build part of the library - like the docs it's very
>> convenient to just create a local CMake project (in a separate directory
>> tree) from <library>/docs/boostbook.
>
>
> And whats the difference between creating a local directory and running
> `cmake --build <some_dir> --target doc`?

right - no difference.  So you don't need the CMakeList.txt in the 
library root directory.  That's my whole point.
>
>
>> Similarly, if I want to just build
>> the library without testing, it's convenient to just create a local
>> CMake project which does this.
>
>
> And you should be able to:
>
> mkdir build && cd build
> cmake --build .
>

right - no difference. So you don't need the CMakeList.txt in the 
library root directory. That's my whole point.

>
>> If you want test using this approach,
>> you'll create a separate build of the library which would be redundant.
>>    But it's not the end of the world.  I'm guessing that boost developers
>> would not be uncomfortable with all this.
>>
>
> But why deal with redundant builds? If you create your cmake like other
> libraries, you wouldn't have this problem. I don't see any advantage to your
> way, only disadvantages.

I don't see any difference.

The standard CMake way has a CMakelists.txt in each subdir

>> Now boost users.
>>
>> Moving to boost users - some might find it convenient to have a library
>> level CMakeList.txt file which includes add-directory.  It it included
>> much else, it might break the ability to make part of the library.  I
>> doubt most boost developers would be happy with this.
>>
>> Actually, the CMake vision is that normal users install a "Package"
>> which doesn't do any testing at all.  So they are not in this game.
>>
>
> What? Any packaging system should allow the ability to run the tests as
> well.

Hmmm - then wouldn't have to presume that all the boost libraries that 
the libraries and tests that the library depends upon would have to be 
included?  So then one would have to couple all the libraries together 
via some convention.  Wouldn't that suggest we have to address the 
problem of dependencies which are different depending upon whether one 
is just building the library or building an testing the library or 
building a particular application which uses the library?

>> On the other hand, If a library level CMakeLists.txt were required and
>> the subdirectory level CMakeLists.txt could not function independently
>> of this, then a user would have to build / test all or nothing.
>
> This is not true at all. You can tell cmake what targets you want to built.

Actually I wasn't really aware of this.  If that's true, then there is 
really no difference. In any case you have to have CMakeLists.txt in 
each subdirectory.  Regardless of whether you use your --build syntax or 
cd to the subdirectory and invoke CMake you'll get the same result.

The only time one needs the library root is when one want's to build all 
the targets.

> Furthermore, all targets that are not part of the library or application
> should
> use the `EXCLUDE_FROM_ALL` property. For example, building hana doesn't
> build
> any tests, only when I build the `check` target, which will build and run
> the
> tests. The same is true for llvm/clang. This convention is quite common not
> just for cmake projects, but for autoconf projects as well.

Arrrrggggghhhh
>
>> I've
>> always wanted to require library users to run all the tests and post the
>> results to a common place. CDash supposedly supports this, but has a
>> number of issues.
>>
>> To summarize, I believe that the only issue here is having a
>> CMakeList.txt in the library root directory.  And I don't think it's a
>> huge issue in the scheme of things.  My view would be that if someone
>> want's to do it - OK - but I think they getting the benefit they think
>> they are.
>>
>
> The benefits of following the conventions makes it familiar for people who
> use cmake and autoconf tools. No one would think that they would need to cd
> into a  directory to build a target.

This would not apply to boost build users.

> Also, it makes it easier to integrate with other tools. For example, I can
> build and install hana with just `cget install boostorg/hana`. I can also
> run the tests as well before installing by using `cget install --test
> boostorg/hana`. The same works for Boost.Compute,

> however, this won't work for serialization(and won't ever).

Hmmmm - why not?

Robert Ramey