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. Similarly, if I want to just build the library without testing, it's convenient to just create a local CMake project which does this. 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. 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. 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. 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. Robert Ramey