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

Subject: Re: [boost] [CMake] what to do now?
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-15 18:45:18

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: 
> > 
> > 
> > On Thursday, April 14, 2016 at 8:47:45 PM UTC-5, Robert Ramey wrote: 
> >> 
> >> On 4/14/16 4:02 PM, Andrey Semashev wrote: 
> >> 
> >>> I think you misunderstood me. You can build sources, docs and tests 
> >>> separately. You can place CMakeLists.txt at the places where Jamfiles 
> >>> currently are. Each of these CMakeLists.txt would declare their own 
> >>> project and could be independent from others. 
> >>> 
> >>> However, the common practice is a bit different. There is typically a 
> >>> single root CMakeLists.txt, which defines a project and then includes 
> a 
> >>> number of nested CMakeLists.txt. The nested CMakeLists.txt may or may 
> >>> not define their projects, that doesn't really matter if you invoke 
> >>> cmake with the root CMakeLists.txt because you're generating makefiles 
> >>> for the whole tree in this case. You can also build targets 
> selectively 
> >>> in this case. 
> >> 
> >> My understanding is quite different. 
> >> 
> >> In each directory one has a CMakeLists.txt file.  This would closely 
> >> correspond to current boost practice. 
> >> 
> >> In addition in the parent directory one creates a CMakeLists.txt 
> >> directory.  It's primary function is to factor common CMake commands 
> >> corresponding to the child directories.  It includes a statement 
> >> add_directory(<child directory name>) for each subdirectory. 
> >> Then when you CMake the parent all the children are "CMaked" after 
> >> having processed the common code in the parent.  As it stands this 
> makes 
> >> sense.  But if you include common CMake commands in the parent you 
> won't 
> >> be able to run CMake on the subdirectories.  So if you want to that, 
> >> just refrain from factoring common code in the parent directory CMake. 
> >> I believe that CMake has an "include" facility so you could have it 
> both 
> >> ways - start from the parent or the children. 
> >> 
> > 
> > Unifying common utilities is not the only reason to have a top-level 
> > directory. The other reason is so users don't have to create multiple 
> build 
> > directories. 
>
> <snip> 
>
> Right 
>
> <snip> 
>
> So CMake and boost build ecourage CMake files in each subdirectory. 
>  Agreed? 
>
> The only question is whether or not a CMakeList.txt file must exist in 
> the parent/library directory. 
>
> My answer is ... it depends. 
>
> 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`?
 

> 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 .
 

> 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.
 

>
> 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.
 

>
> 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.
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.
 

> 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.

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).
 

>
> Robert Ramey 
>
>
> _______________________________________________ 
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost 
>