Post by TylerPost by Michael HertlingPost by Tomasz GrobelnyPost by Alexander NeundorfPost by Tomasz GrobelnyPost by TylerOn Mon, Apr 11, 2011 at 8:54 AM, Tomasz Grobelny
Post by Tomasz GrobelnyOk, 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
Post by TylerPost by Tomasz Grobelnyvariable (provided he knows about MYDESTDIR)? Maybe it is possible
to
haven't
it),
Post by Michael HertlingPost by Tomasz GrobelnyPost by Alexander NeundorfPost by Tomasz GrobelnyPost by Tylermaybe 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
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
Post by Michael HertlingPost by Tomasz GrobelnyPost by Alexander NeundorfPost by Tomasz Grobelnyto avoid that if at all possible.
DESTDIR has a different purpose.
Installing to DESTDIR does not necessarily lead to a working and
correct
settings.
Post by Michael HertlingPost by Tomasz GrobelnyPost by Alexander NeundorfAssuming 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
Post by Michael HertlingPost by Tomasz Grobelnynot
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.
Somewhat hackish (especially this \$\(firstword \$\(MAKEFILE_LIST\)\)
Hackish, ugly, non-portable and absolutely inadvisable. ;-)
Post by Tylerpart). I've just come up with another solution (probably not less hackish,
set(CMAKE_INSTALL_PREFIX "\$ENV{MYDESTDIR}")
That's not hackish, IMO, but even quite elegant, indeed. Nevertheless,
the limitations and risks mentioned earlier in this thread still hold.
A rather obvious example for the shortcomings of that approach is the
installation of a configuration file for the concerned package; see
the following CMakeLists.txt for a highly rudimentary realisation:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(MYDESTDIR C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(CMAKE_INSTALL_PREFIX "\$ENV{MYDESTDIR}")
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
ADD_LIBRARY(f SHARED f.c)
FILE(WRITE ${CMAKE_BINARY_DIR}/f-config.cmake "FIND_LIBRARY(
F_LIBRARY f PATHS ${CMAKE_INSTALL_PREFIX}/lib NO_DEFAULT_PATH
)\n")
INSTALL(TARGETS f LIBRARY DESTINATION lib)
INSTALL(FILES ${CMAKE_BINARY_DIR}/f-config.cmake DESTINATION share)
Here, $ENV{MYDESTDIR} will end up as the installation prefix in the
config file, so another project that calls FIND_PACKAGE(f) to learn
about libf.so's location would need to have MYDESTDIR defined in its
environment. Thus, you extend the need for this environment variable
from your project to your project's users, i.e. you're about to shoot
yourself in the foot, and even worse, you're about to shoot in another
one's foot. OK, you might do some last-minute-modifications during the
installation with INSTALL(CODE/SCRIPT ...), or you might try to use the
CMAKE_CURRENT_LIST_FILE variable to find a way from the config file to
the library as it is done in the export files from INSTALL(EXPORT ...),
but I wonder if this can be set up in a bullet-proof way. To summarize,
delaying the expansion of CMAKE_INSTALL_PREFIX up to the installation
is most inconvenient for projects which install configuration files.
Regarding this and the already mentioned issues in this respect, for
what reason should one bank on an installation prefix evaluated at
installation time? Just because the users are accustomed to "make
install MYDESTDIR=..."? As I said before, I think that this is
worth neither the effort nor the limitations nor the risks.
Regards,
Michael