[CMake] Configuring external projects with cmake for a nonexistent install directory which is not configure-time writable

[The Wanderer]

On 03/14/2011 11:05 AM, Eric Noulard wrote:

> 2011/3/14 The Wanderer <wanderer at 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.