[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