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