On 18/05/2016 12:31, Paul Fultz II wrote:
On Tuesday, May 17, 2016 at 7:07:44 PM UTC-5, Peter Dimov wrote:
Paul Fultz II wrote:
The tool doesn't look for CMakeLists.txt at all. It just calls cmake on the library. If you want it to search in another location, its best to update cmake to do that.
cmake takes the directory as an argument, so it would make absolutely no sense for it to search. If you want cmake to look for CMakeLists.txt somewhere, you pass that somewhere to it.
That is true, but considering putting a cmake in another directory is first, quite rare, and also non-conventional. Therefore, it is difficult to decide what directory should be searched, and in what order the search to happen. Its much simpler to just put the cmake file where it is expected to be.
My experience is admittedly limited (most projects I use build using VS or autotools; cmake is comparatively rare), but most that I have seen either put the CMakeLists.txt file in the root or in a cmake subdirectory. More importantly, however, is that you *never* run cmake in the same directory as the CMakeLists.txt file, so you never run it without parameters. Without exception (in my limited experience) the instructions are to create and switch to a build subdirectory and run cmake in that, pointing it at the other directory (typically .. or ../cmake) that actually contains the CMakeLists.txt. (This is important because CMake lacks the ability to clean up after itself, unlike autotools, so you need to keep it segregated from the original source.) So I don't see why it'd be weird for Boost to put the CMakeLists.txt in cmake/ or build/.