At 7/24/2008 08:26 AM, Hendrik Sattler wrote:
Zitat von David Boosalis <[EMAIL PROTECTED]>:
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.
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
