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