[CMake] CMAKE equivalent of qmake's MOC_DIR

[Sebastien BARRE]

At 7/24/2008 08:26 AM, Hendrik Sattler wrote:
>Zitat von David Boosalis <dn31415 at yahoo.com>:
>
>>The one complaint I have with building in another directory is when
>>working with emacs.  I like to do my make inside of emacs, that way
>>when there is a compile error message I can click on it from emacs
>>and it takes me right to the offending line.  The only problem is
>>that if I have to close all files after editing them as emacs gets
>>confused if a file is open, and assumes the build is where the
>>source file is, so it fails.
>>
>>Emacs users hate doing extra steps such as closing files ( I hav eto
>>  do a extra  key stroke operation for each file that is open (to
>>close file)  before recompiling from the build directory.
>
>Then don't.
>M-x compile
>Now add: -C <full-path-to-binary-dir>
>
>It will remember that on the next compile invocation. Yes, it assumes
>compilation in the current directory. You can probably use some
>Lisp-Hack to automatically modify the compile command to "the right
>thing" on emacs startup...

Yes, you can definitely do that, I wrote some Lisp code years and 
years ago to handle these scenarios.
I could look at re-factorizing it and put it in the CMake emacs file.

Basically I have lists of that form:

     ("CMake"
      ((concat (getenv "SRC") "/kitware/CMake") (getenv "SRC") "~/src")
      ((concat (getenv "BUILD") "/kitware/CMake") (getenv "BUILD") "~/build")
      (
       ("CMake 2.6"
        ("CMake-CMake-2-6")
        ("Modules"
         "Source"
         "Source/MFCDialog"
         "Templates")
        ("CMake-CMake-2-6-nmake-debug"
         "CMake-CMake-2-6-nmake-release"
         "CMake-CMake-2-6-debug"
         "CMake-CMake-2-6-release")
        )
       ("CMake"
        ("CMake-HEAD")
        ("Modules"
         "Source")
        ("CMake-HEAD-nmake-debug"
         "CMake-HEAD-debug")
        )
       )
      )

Where SRC and BUILD are two environment variables I set to the very 
top of my source trees, on Windows they are d:/src, and d:/build. 
Within each I usually have a "kitware" subdir, and within this 
subdir, a top directory for each project (for example 
"d:/src/kitware/CMake" to store all my CMake source trees, i.e. the 
HEAD, the 2.6 branch, etc, and "d:/build/kitware/CMake" to store all 
my CMake build trees, i,.e. the HEAD build tree using make in debug 
mode, another one in release, two others for 2.6, some with Visual 
Studio, etc.)). Repeat for other projects, VTK, ITK, you get the 
idea. On Unix though, I drop the "kitware" subdir because I got tried 
of typing :)

Anyway, this list first describes (in line 2 and 3) where I could 
potentially find CMake source and build trees (i.e. relative to  the 
SRC and BUILD env variable, or just in ENV(SRC), or just in ~/src or 
~/build on Unix, etc). Following those 2 lines, I have a description 
of each potential source-build pair, the first one is CMake 2.6 here, 
which usually has a source tree named CMake-CMake-2-6 by convention, 
and build trees that can be named CMake-CMake-2-6-nmake-debug, 
CMake-CMake-2-6-nmake-release, etc (4 candidates here). Then you can 
see the same description for the CMake HEAD.  I also describe 
potential subdirs where additional source code can be found (here 
"Modules", "Source", "Source/MFCDialog"), but you can totally discard 
that, it's for another piece of code that auto-locate source files 
and header files (very handy).

When I hit F9, I loop over all the projects, all their source trees, 
and check if the current buffer is part of  one of them (the best 
match). If I find a match, I run "make" from Emacs at the top of the 
corresponding build tree (as described by the structure above). They 
are ordered by preference though, since two build trees can obviously 
use the same source tree, here "CMake-CMake-2-6-nmake-debug" and 
"CMake-CMake-2-6-nmake-release" use the same "CMake-CMake-2-6" source 
tree. I didn't write code to detect that situation and eventually ask 
the user which one he wants to build in; 99% of the time I put the 
debug tree first where I do all my development and that's the one 
that is picked to run "make" (or "nmake") in. When it's time to 
deliver a static release, I just do it at the command prompt in a 
different window, etc.

That's the idea.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20080724/19c74068/attachment-0001.htm>