On Wed, Jun 1, 2016 at 3:56 AM, Michael Caisse wrote:

On 6/1/16 01:29, Andrey Semashev wrote:

...

On Wednesday, 1 June 2016 11:28:12 MSK David Sankel wrote:

...

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.

I think Rene said that this was not prohibited multiple times in the discussion.

We are having this discussion because there might have been confusion on what Rene meant here:

I don't think that's the only reason we are having that discussion ;-) But.. http://lists.boost.org/Archives/boost/2016/04/229030.php Perhaps I should have been more clear at that time :-\ I wasn't trying to exclude the latter part of the statement I quoted. I was trying to clarify that it's a requirement to have build/CMakeLists.txt (or build/makefile, or build/vs2012.prj, or build/SConstruct, etc) as opposed to a recommendation. Which I think I made clear at some point in the conversation currently in question. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On Thu, Jun 2, 2016 at 7:26 PM, Louis Dionne wrote:

David Sankel 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.

Ignoring the rest of your reply as directed :). I'm not making any suggestions here. I'm just relating the feedback provided by some individuals. It doesn't constitute anything like an official recommendation. The main result is that there is nothing preventing you from providing a CMakeLists.txt in the root directory of your distribution. The advice provided by others was made in good will for your benefit, but it's ultimately up to you to make the decisions for Hana. We're entrusting you to make the best call given all the information. -- David

Steven Watanabe writes:

AMDG

On 06/02/2016 07:26 PM, Louis Dionne wrote:

...

[...]

All of these arguments depend solely on the existence of build/, regardless of whether it contains a CMakeLists.txt or not. For separately compiled libraries, build/ *must* exist because that's the layout that we've chosen for Boost.Build.

I understand that, and would conform if Hana had something to build.

For header-only libraries, like hana, it's not needed and should not exist, making this point moot. I just looked at your top-level CMakeLists.txt and it seems like it should be acceptable even by the strictest possible reading of the requirements. It definitely does not belong in build/.

Yay! Then all is fine as far as I'm concerned. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/A-retrospect-on-CMakeLists-txt-policy-rev... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Fri, Jun 3, 2016 at 10:21 AM, Paul Fultz II wrote:

...

On Jun 2, 2016, at 8:50 PM, Steven Watanabe wrote:

All of these arguments depend solely on the existence of build/, regardless of whether it contains a CMakeLists.txt or not. For separately compiled libraries, build/ *must* exist because that's the layout that we've chosen for Boost.Build.

Thats the layout for Boost.Build, but what about cmake?

It's not a Boost Build layout.. It's a "Boost C++ Libraries" layout. It's what the community of library authors decided as a directory layout for libraries. We are free to change it after discussions, consensus, etc. But probably not a discussion for this thread ;-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 3/06/2016 13:26, Louis Dionne wrote:

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.

You can't use (libroot)/build as the cmake output directory anyway, since it includes source files (at least jamfiles, if nothing else) -- and since cmake lacks the ability to clean its output, you have to delete the directory to do so. To me, logical choices seem to be one of the following: 1. Use (libroot)/build/build as the cmake output directory. In this case, you should put *no* cmake files into (libroot), and the "main" cmake file into (libroot)/build (possibly supporting files elsewhere). You can now use *exactly* the normal cmake build incantations as you normally would; you just cd into (libroot)/build before "mkdir build; cd build; cmake .." etc. 2. Use some other directory as the cmake output directory. In this case it is possibly convenient to put a cmake file into (libroot), but TBH I don't really see the point. You have to point cmake at both the output and source directories anyway -- there's very little difference between any of these: cd $libroot; mkdir output; cd output; cmake .. cd $libroot; mkdir output; cd output; cmake ../build cd ~; mkdir libbuild; cd libbuild; cmake $libroot/build (I assume that you're not suggesting that Boost libraries stop putting files into (libroot)/build so that it can be used as the output directory. Boost used that name before CMake AFAIK, and CMake doesn't require it while Boost does.)

2. Use some other directory as the cmake output directory. I always put the build outside the whole tree. I thought everyone did and I thought that's was the normal/recommended/customary

On 6/2/16 6:52 PM, Gavin Lambert wrote: practice when using CMake.

Robert Ramey writes:

On 6/2/16 6:52 PM, Gavin Lambert wrote:

...

2. Use some other directory as the cmake output directory. I always put the build outside the whole tree. I thought everyone did and I thought that's was the normal/recommended/customary practice when using CMake.

I always assumed that "out of source build" meant that all the products were in their own separate directory, (i.e. root/build/), but not necessarily meaning that the directory was out of the source tree (i.e. root/../build). I think the goal is to not end up with .o files alongside .cpp files, nothing more, but I could be mistaken. Using root/../build is cumbersome because the build directory will conflict if you have many different projects. Imagine for example /home/ldionne/code/ project1/ build/ <-- build tree for project1 project2/ build/ <-- can't be called build Instead, I like to have /home/ldionne/code/ project1/ build/ project2/ build/ ... and so on Just my preference. Louis