Re: [boost] A retrospect on 'CMakeLists.txt' policy review

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.

Regards,
Louis