Subject: Re: [boost] A retrospect on 'CMakeLists.txt' policy review
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-06-02 21:52:32
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
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.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk