<html>
<body>
At 7/24/2008 08:26 AM, Hendrik Sattler wrote:<br>
<blockquote type=cite class=cite cite="">Zitat von David Boosalis
<dn31415@yahoo.com>:<br><br>
<blockquote type=cite class=cite cite="">The one complaint I have with
building in another directory is when <br>
working with emacs. I like to do my make inside of emacs, that
way <br>
when there is a compile error message I can click on it from
emacs <br>
and it takes me right to the offending line. The only problem
is <br>
that if I have to close all files after editing them as emacs
gets <br>
confused if a file is open, and assumes the build is where
the <br>
source file is, so it fails. <br><br>
Emacs users hate doing extra steps such as closing files ( I hav
eto <br>
do a extra key stroke operation for each file that is open
(to <br>
close file) before recompiling from the build
directory.</blockquote><br>
Then don't.<br>
M-x compile<br>
Now add: -C <full-path-to-binary-dir><br><br>
It will remember that on the next compile invocation. Yes, it
assumes <br>
compilation in the current directory. You can probably use some
<br>
Lisp-Hack to automatically modify the compile command to "the
right <br>
thing" on emacs startup...</blockquote><br>
Yes, you can definitely do that, I wrote some Lisp code years and years
ago to handle these scenarios.<br>
I could look at re-factorizing it and put it in the CMake emacs
file.<br>
<x-tab> </x-tab><br>
Basically I have lists of that form:<br><br>
<tt> ("CMake"<br>
((concat (getenv "SRC")
"/kitware/CMake") (getenv "SRC")
"~/src")<br>
((concat (getenv "BUILD")
"/kitware/CMake") (getenv "BUILD")
"~/build")<br>
(<br>
("CMake 2.6"<br>
("CMake-CMake-2-6")<br>
("Modules"<br>
"Source"<br>
"Source/MFCDialog"<br>
"Templates")<br>
("CMake-CMake-2-6-nmake-debug" <br>
"CMake-CMake-2-6-nmake-release" <br>
"CMake-CMake-2-6-debug"<br>
"CMake-CMake-2-6-release")<br>
)<br>
("CMake"<br>
("CMake-HEAD")<br>
("Modules"<br>
"Source")<br>
("CMake-HEAD-nmake-debug"
<br>
"CMake-HEAD-debug")<br>
)<br>
)<br>
)<br><br>
</tt>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 :)<br><br>
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).<br><br>
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.<br><br>
That's the idea. </body>
</html>