[CMake] Execution order

[Michael Wild]

Ok, to clear things up:

Source tree: here are all the source files (*.h, *.cpp, CMakeLists.txt, etc). It's the stuff you check into your version control system.

Build tree (a.k.a binary tree): here go all the products (i.e. generated files, like CMakeCache.txt, cmake_install.cmake, *.o, libraries, executables etc.).

It is usually a very good idea to completely separate these two directory trees. This has the advantage that you can get rid of all the generated files by simply removing the build tree, not having to worry about accidentally deleting any source files. It also saves you from manually picking through the clutter of generated files and to remove them individually.

Also, you can have multiple build trees, using different configurations (debug, release, with crypto libraries, pure opensource, with commercial components, 64-bit, 32-bit, etc) side by side and have them use a single copy of the source tree.

So, I usually have something like this:

~/Projects/super_duper                   <--- source tree
~/Projects/super_duper-build/debug       <--- debugging build tree
~/Projects/super_duper-build/release     <--- release build tree
~/Projects/super_duper-build/dashboards  <--- parent directory for dashboard builds

I hope you get the idea.

Then, when I e.g. want to set up the debugging tree, I do:

# create the build tree
mkdir -p ~/Projects/super_duper-build/debug
# change directory to it
cd $_
# run cmake, telling it I want a debugging build and pointing it to the source tree
cmake -DCMAKE_BUILD_TYPE=Debug ~/Projects/super_duper
# kick off the build
make


HTH

Michael

On 17. Sep, 2010, at 14:43 , David Aldrich wrote:

> Hi Ryan
> 
> Thanks for your reply.
> 
> CMakeLists.txt always lives in the source directory I assume?
> 
> If it does live with the source, is there anyway of moving the clutter of cmake_install.cmake, CMakeFiles etc. in the source directory?
> David
> 
> From: Ryan Pavlik [mailto:rpavlik at iastate.edu]
> Sent: 17 September 2010 13:07
> To: David Aldrich
> Cc: Chris Hillery; cmake at cmake.org
> Subject: Re: [CMake] Execution order
> 
> Your build system would be independent where the output files are: the user can choose whatever build directory they want, and not be limited to _gnuDebug and _gnuRelease.  (If they so chose, they could create each of those and configure a build into them, but they are just as likely to not do so. Actually, as I look at your info again, it looks like you're making lots of those _gnuRelease directories - that definitely looks like an in-source build.)  If that's a policy you want to encourage in your organization, that's just fine, but to CMake, you should keep things relative to CMAKE_SOURCE_DIR/CMAKE_CURRENT_SOURCE_DIR and CMAKE_BINARY_DIR/CMAKE_CURRENT_BINARY_DIR.  The general guideline is to never modify or generate anything into the _SOURCE_DIR - only into the _BINARY_DIR, that way you can get back to a clean source tree by just deleting the build directory.  The makefiles generated by CMake will all be in the binary directory (and as a preemptive warning: don't commit the generated makefiles to source control, they are not machine-independent), so that's where you'd run make.
> 
> Hope this helps!
> 
> Ryan
> On Fri, Sep 17, 2010 at 6:24 AM, David Aldrich <David.Aldrich at eu.nec.com<mailto:David.Aldrich at eu.nec.com>> wrote:
> Hi Chris
> 
>> No, you shouldn't have to, unless you're using in-source builds
>> which is very strongly deprecated. Once you've gotten used to
>> out-of-source builds you'll never want to go back.
> Ok, I'm trying to think of how this would work for us.
> 
> The source for each of our libraries is in a separate subdirectory as you would expect. The subdirectory structure is:
> 
> Subdir ----- .cpp files
>        |
>        |-- Makefile
>        |
>        |-- _gnuDebug      <=== .o and .a files for Debug build
>        |
>        |-- _gnuRelease    <=== .o and .a files for Release build
> 
> Would you call that an out-of-source build, or would you require the Makefile to be in a 'Build' subdirectory below the source?
> 
> Or, would you really like to see the build files somewhere to the side of the source files?
> 
> Best regards
> 
> David
> _______________________________________________
> Powered by www.kitware.com<http://www.kitware.com>
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
> 
> 
> 
> --
> Ryan Pavlik
> HCI Graduate Student
> Virtual Reality Applications Center
> Iowa State University
> 
> rpavlik at iastate.edu<mailto:rpavlik at iastate.edu>
> http://academic.cleardefinition.com
> Internal VRAC/HCI Site: http://tinyurl.com/rpavlik
> 
> 
> Click here<https://www.mailcontrol.com/sr/sDHIg6kU9Y3TndxI!oX7UkEBkbd6cai+DXsVObJbxJ9BToqwBJZDqD0mc0MEr5X2KiXbDbOtE1JPcbrY0G8NdQ==> to report this email as spam.
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake

--
There is always a well-known solution to every human problem -- neat, plausible, and wrong.
H. L. Mencken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100917/c7a0eebd/attachment-0001.pgp>