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

[Michael Wild]

On 03/14/2011 04:46 PM, The Wanderer wrote:
> 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?
> 

Please note that my remark about "improper" use of the ExternalProject
module only reflects my opinion and my experiences with it. Exactly
because of the trouble you have run into, I prefer to have the external
project install into the build tree, and then install the files required
by the client project from the client project.

Just out of curiosity, what is that project you're talking about? I'd
like to have a look at it.

Also, the documentation of ExternalProject_Add() should probably be
extended and explain these issues.

Michael