On 03/14/2011 11:05 AM, Eric Noulard wrote:
2011/3/14 The Wanderer <wande...@fastmail.fm>:
(I apologize for setting the Reply-To header, but I know of no
other way to prevent my being sent an additional off-list copy of
any reply even when there is no specific need to draw my attention
to that reply.)
I am running cmake 2.8.2, installed via Debian testing. No more
recent version appears to be available via Debian.
Yes there is 2.84 in SID:
http://packages.debian.org/sid/cmake
I apologize. I ordinarily track sid on this machine, and when I checked
available versions of the cmake package, I did not notice that it
reported 2.8.2 against testing and stable rather than against testing
and unstable.
I am attempting to compile a project which has recently switched to
cmake after a long time spent on autotools.
The project uses, and includes the source to, at least two other
projects, which it treats as external projects.
The project explicitly requires (and enforces) an out-of-tree
build.
I habitually install each new version of this particular project
under its own brand-new prefix, to more easily retain previous
versions for fallback if necessary. As a consequence, the target
install prefix does not exist at the beginning of the build
process.
I configure and compile as an ordinary user, which does not have
write access to the install location. It has long been my
understanding that this is ordinarily considered good practice.
I am attempting to configure with the command line
----
cmake /path/to/source -DDEBUG=1 -DPREFIX=/path/to/nonexistent/install/dir
----
With this command, the configure process fails. The error message
is:
We do not have enough information about your CMakeLists.txt.
ExternalProject_Add do have some options like:
PREFIX
TMP_DIR
DOWNLOAD_DIR etc...
which may be different from the install prefix of your project.
So I'm not using ExternalProject_Add myself but I suspect you are
making assumption on when action take place which may be different
from the module designers.
I let ExternalProject_Add users comment that part.
Michael Wild's response appears to be correct. In the CMakeLists.txt
provided for the external project in question, INSTALL_DIR is being
explicitly set to ${CMAKE_INSTALL_PREFIX}. This did not appear to be
obviously incorrect, but apparently it is. I will report the problem to
the project.
In this case, the "external" project is distributed along with the
"master" project, and the CMakeLists.txt for the external project
contains pretty much only setup code for ExternalProject use; in other
words, there is no way to use cmake to configure the external project as
a standalone (non-external) build. Am I correct that this is also not
normal practice, and that e.g. the ExternalProject_Add calls should be
made from the "master" project's CMakeLists.txt?
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
_______________________________________________
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
