David, I think a bit more explanation of the philosophy (at least how I interpret it) is needed. I see in your emails that you are “targeting makefiles”. With CMake you need to really stop thinking this way. Rarely do you need to target any specific build system (although those times do come up…). A lot of folks I see coming from autoconf to CMake still try to treat CMake in the same way. Don’t. There are a few golden rules with CMake that if you adhere to those will allow you to use CMake much easier.
1: NEVER have the Source directory and the Build directory be the same place. 2: PREFER out-of-source build directories (Not required but helpful) 3: Try not to target specific generators (makefiles, visual studio, xcode) What this looks like is the following. Say I have a project from github called Foo and I clone it onto my local filesystem. From a command line perspective you get the following: Git clone https://github.com/somebody/Foo The *Preferred* way is this Clone Foo *At the same directory level as Foo* Mkdir Debug && cd Debug Cmake -DCMAKE_BUILD_TYPE=Release ../Foo # We can break rule 2 a bit by making subdirectories inside of Foo cd Foo mkdir Debug && cd Debug cmake -DCMAKE_BUILD_TYPE=Debug ../ make -j We have just created a Debug build in the Debug Directory. Now, the same is analogous for the Release build. Cd Foo Mkdir Release && cd Release Cmake -DCMAKE_BUILD_TYPE=Release ../ Make -j *IF* you make these subdirectories in a source code top level be sure to add those directory names to the .gitignore file. If your cmake is written properly then the build creates NOTHING inside of the source directory. I hope this helps summarize all of the other emails. Glad to have you in the CMake community. -- Mike Jackson From: CMake <cmake-boun...@cmake.org> on behalf of David Aldrich <david.aldrich.n...@gmail.com> Date: Friday, June 21, 2019 at 12:10 PM To: Braden McDaniel <bra...@endoframe.com> Cc: CMake <cmake@cmake.org> Subject: Re: [CMake] How to support separate debug and release build directories? > What would best practice be to provide convenient commands for our > developers to easily build the target ? For the Makefile generator, best practice is to use separate build directories (i.e., places where you run cmake) for different configurations (i.e., different settings recorded during the configuration step). If you want to provide developers with some known set(s) of configuration settings, I suggest wrapper scripts that invoke cmake with those settings. Thanks for your advice. I am not finding it easy to find 'patterns' for these sort of issues. I would have thought that configuring a project with separate debug and release directories would be quite typical. But it's hard to find the recommended way of doing such things. Anyway, I think I am on the right track now. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
