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
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.)