David Sankel
Hello all,
I wanted to thank everyone who participated in the CMakeLists.txt and related threads. I'm sorry I wasn't able to participate all the way through, but I found the majority of the posts to be civil and constructive (some of my own heated posts being notable exceptions).
Thanks to you for starting the discussion on the list and to all of those who participated. For those that don't know, I was in the bunch of people that started floating this at C++Now, but unfortunately I couldn't follow the mailing list closely when the discussion started because I was moving to a different country. I did read most discussions after the fact, though.
Here is my take away. No one is arguing that the current guidelines disallow authors from placing a CMakeLists.txt in the root of their library's directory. Some pointed out drawbacks of placing them there and recommended 'build/' or 'CMake/' instead. Others saw value in having CMakeLists.txt in the root directory, but felt these should be short wrappers where the real work is done in the 'build/' directory.
Louis and Paul, I know you felt it important for your gitHub distribution to have 'CMakeLists.txt' in the root directory as is typical for CMake projects. Does this result satisfy your concerns?
IIUC, you suggest that we have both a CMakeLists.txt at the root and one in build/, with the one in build/ possibly doing the "real" stuff and the one at the root just forwarding to build/. Is this correct? If not, please completely ignore the rest of my reply below. If I understand correctly, however, then I might be inflexible but having a CMake file in the build/ directory is still a major annoyance, as it disturbs the usual CMake workflow. The build/ directory is normally used for products, and as such it contains no source files. This means that we can't put build/ in the .gitignore file, and that we can't simply delete the build/ directory to clean things up. That disturbs the usual CMake workflow, and I don't think this is acceptable. I'll actually make an even bolder statement: I think we shouldn't regulate on specific libraries beyond what's required for Boost to work. In other words, if you need to impose conventions such as having a Jamfile, include/, src/ and test/ directories, and building the tests + documentation through a specific build system and using specific targets (as done right now), then I'm totally fine with this, because it's required for Boost to actually work. In fact, I created Jamfiles for Hana as soon as it was accepted in Boost and I tried to conform to the guidelines as much as possible, even more than most libraries did. I'm OK with all of this. However, what I'm not OK with is having to change my personal workflow (even a bit) _to satisfy some people's ideologies_ about conformity in Boost and other similar things. Especially since most of these people don't use Hana, are not affected the least by the location of the CMakeLists.txt file, and might not even use CMake anyway. Hence, unless the community decides to move to CMake, in which case the location of the CMakeLists and its contents would matter -- and I would conform to the choices of the community -- I do not plan on changing Hana's directory structure. Fortunately, this will not break anything because nothing in Boost relies on this. And please observe that I am __NOT__ proposing that we move to CMake, and I would appreciate it if nobody spinned off a thread about the future of Boost from this reply. I know this makes it sound like I'm just stubborn; it's not the case. If someone has valid __technical__ arguments for doing otherwise, I will happily discuss and perhaps stand corrected. Regards, Louis