Subject: Re: [boost] A retrospect on 'CMakeLists.txt' policy review
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2016-06-02 21:26:59
David Sankel <camior <at> gmail.com> writes:
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk