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 20:47:10

On Friday, April 15, 2016 at 7:01:27 PM UTC-5, Robert Ramey wrote:
>
> 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. 
>

Redundant builds is a big difference.
 

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

This is common but not necessary. Zlib doesn't put a cmake in each 
directory,
neither does the Fit library.
 

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

Yes, of course, it will need to track test dependencies separate from the 
build
dependencies. Cget already does that, I don't see that as problematic.
 

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

Except as a user I would need to figure out the folder structure of your
library before building, instead of invoking the standard `all` or `install`
target.
 

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

Which is very few users of boost, as most boost users use some form of
autotools, cmake, make, visual studio, etc.
 

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

Because it doesn't have a CMakeLists.txt in the root directory.
 

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