On 04/11/2011 10:42 PM, Tomasz Grobelny wrote:
> On Monday 11 April 2011 21:55:48 Alexander Neundorf wrote:
>> On Monday 11 April 2011, Tomasz Grobelny wrote:
>>> On Mon, 11 Apr 2011 09:01:09 -0700, Tyler <ty...@cryptio.net> wrote:
>>>> On Mon, Apr 11, 2011 at 8:54 AM, Tomasz Grobelny
>>>>
>>>> <tom...@grobelny.oswiecenia.net> wrote:
>>>>> Ok, but is there a way to achieve the same effect so that the user can
>>>>> type just "make install" and not know anything about DESTDIR
>>> environment
>>>>> variable (provided he knows about MYDESTDIR)? Maybe it is possible to
>>>>> put this "DESTDIR=$MYDESTDIR" in the generated Makefiles somehow...
>>>>
>>>> If I understand your use case right (which I might not as you haven't
>>>> described what you're trying to do, just how you're trying to do it),
>>>> maybe you can just override CMAKE_INSTALL_PREFIX.
>>>>
>>>> If you go this route, check the archives because of the whole
>>>> _INITIALIZED_TO_DEFAULT aspect of that particular cache variable.
>>>
>>> I already tried playing with CMAKE_INSTALL_PREFIX but the problem was
>>> that value of MYDESTDIR was read (and saved to CMAKE_INSTALL_PREFIX)
>>> only when configuring first time. That's why DESTDIR mechanism comes
>>> closer to what I'm trying to achieve. My use case is something like
>>> that:
>>> 1. User has some default MYDESTDIR to non writable location.
>>> 2. User executes "cmake . && make install".
>>> 3. The installation fails because user has no rights to $MYDESTDIR.
>>> 4. User changes MYDESTDIR to another location (writable this time).
>>> 5. User executes "make install" once again and it should succeed.
>>>
>>> Of course the user could set MYDESTDIR to correct location before
>>> building but people often forget that. Now the tricky part is that users
>>> are already used to this mechanism (for particular variable name, called
>>> MYDESTDIR here). So taking different environment variable instead of
>>> DESTDIR would allow me to minimize confusion among users. Otherwise I'll
>>> just tell them to set yet another variable (DESTDIR). But I would like
>>> to avoid that if at all possible.
>>
>> DESTDIR has a different purpose.
>> Installing to DESTDIR does not necessarily lead to a working and correct
>> installation, mainly when paths are involved, like e.g. RPATH settings.
>> Assuming that CMAKE_INSTALL_PREFIX would be /opt/foo, your executable might
>> get /opt/foo/lib as RPATH, also when installed to $DESTDIR/opt/foo.
>> So they will not have a correct RPATH.
>> You really should set CMAKE_INSTALL_PREFIX.
>>
> I'd like to. But CMAKE_INSTALL_PREFIX does not get recomputed when I change
> MYDESTDIR and try to do "make install" again. Or at least I don't know how to
> make it behave this way.
> Besides, I don't use RPATH (at least not explicitely, hopefully cmake is not
> doing anything nasty behind the scenes).
But some day, you might want to use RPATH features as they are very
convenient in certain situations, or you might want to incorporate
the installation prefix or derivatives like CMAKE_INSTALL_PREFIX/lib
/${PROJECT_NAME} in your binaries which can be quite convenient, too.
Moreover, you can hardly prevent your project's users to use RPATH on
their own, see the CMAKE_INSTALL_RPATH/CMAKE_BUILD_WITH_INSTALL_RPATH
variables, e.g. In this regard, using the DESTDIR Makefile/environment
variable bears the risk of subtle failures and isn't worth the effort,
IMO. Thus, you should take Alex's warning absolutely seriously, or in
other words: Changing the installation prefix does invalidate your
already built targets, so you do need to reconfigure and rebuild.
Anyway, see [1] for a chance to add "DESTDIR=$MYDESTDIR" to the
generated Makefiles, provided that you are using GNU Make, but
even this won't work as expected since DESTDIR is hard-coded
in CMake, AFAIK, and due to other reasons.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg34344.html
_______________________________________________
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
