[CMake] INSTALL when source file is already at DESTINATION?

Eric Noulard eric.noulard at gmail.com
Thu Dec 16 02:47:42 EST 2010


2010/12/16 Gregory Peele ARA/CFD <gpeele at ara.com>:
> Hi all,
>
> What is the expected behavior is for INSTALL (TARGETS) when the source file
> for a particular destination is already at the relevant DESTINATION?  For
> example, this could happen with a  Unix Makefile generator for "LIBRARY
> DESTINATION lib" when CMAKE_INSTALL_PREFIX/lib and
> CMAKE_LIBRARY_OUTPUT_DIRECTORY are the same path - the latter having been
> set differently than the default of course.
>
> In practice it seems like this case works fine for all types of targets in
> Windows/MSVC generators, and fails only for shared objects in Linux/Unix
> Makefiles.  It might even only fail for shared objects with SOVERSION
> symlinks but I haven't confirmed that yet.    The actual shared library is
> being deleted at some point after build (leaving a dangling symlink) and
> then the INSTALL step fails because its source file is missing.

Would you have an example with file names?
For example I have some shared lib with so version and I get (in the build dir)*

(1) libCERTId.so -> libCERTId.so.3
(2) libCERTId.so.3 -> libCERTId.so.3.4.1cvs
(3) libCERTId.so.3.4.1cvs

then I get the same set of files and symlinks in the (separate) install tree.
Do you mean that in your case the plain file (3) is deleted ?

> Not a big deal for me since this only comes up in very controlled
> circumstances in my project that are handled by macros - I skip the TARGETS
> install step when this will happen.   I'm just curious if this failure is
> expected or could be considered a minor bug.

My point of view would be that this is a user mistake and the best CMake can do
would be  to warn about the collision and simply avoid "install onto
myself" case.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org


More information about the CMake mailing list