Re: [CMake] How not to copy a link
On 01/11/2012 04:52 PM, David Cole wrote:
On Wed, Jan 11, 2012 at 10:10 AM, Michael Hertling mhertl...@online.de
wrote:
On 01/07/2012 03:52 PM, David Cole wrote:
On Sat, Jan 7, 2012 at 9:47 AM, David Cole david.c...@kitware.com wrote:
On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling mhertl...@online.de
wrote:
On 01/06/2012 07:51 PM, Kevin Burge wrote:
Thanks David. These are external libraries built outside of CMake,
without CMake, not imported via any of the import capabilities of cmake,
and that need to be installed alongside my CMake built files. I think
I'm just going to do the install with the rename. Requires me to be
more explicit, but, it's not like it changes all that frequently.
Isn't it sufficient to copy such SONAME symlinks as they are, along with
the actual library files, of course? Having a symlink from the SONAME to
the library file is a basic mean of the ABI management on platforms with
advanced - ;-) - support of shared libraries. Besides, these symlinks
are automatically created by ldconfig when the latter processes the
directory.
Anyway, w.r.t. your initial question, I'd usually suggest to use the
GET_FILENAME_COMPONENT(... REALPATH) command on the symlink prior
to the INSTALL() command, but it seems to not work as expected:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
touch xyz.dat.0)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
create_symlink xyz.dat.0 xyz.dat)
GET_FILENAME_COMPONENT(XYZ xyz.dat REALPATH)
MESSAGE(XYZ: ${XYZ})
Due to the documentation of GET_FILENAME_COMPONENT(... REALPATH),
... the full path with *all* symlinks resolved (REALPATH).
I'd expect to see
XYZ: .../xyz.dat.0
instead of
XYZ: .../xyz.dat
Do I misunderstand GET_FILENAME_COMPONENT() in respect thereof?
Regards,
Michael
On 01/06/12 12:45, David Cole wrote:
Have you considered setting the VERSION and SOVERSION target
properties on your libraries instead of doing the symlinks yourself?
CMake will build and install the symlinks automatically for you on
platforms where they are supported if you set these target properties.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION
(Or was that just an example, and you need to do this with other
symlink files that are not simply the version symlinks for a
library...?)
HTH,
David
--
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
It works if you use:
GET_FILENAME_COMPONENT(XYZ ${CMAKE_CURRENT_BINARY_DIR}/xyz.dat REALPATH)
I'm not 100% sure if the behavior is expected to be defined for
non-full paths. Hopefully Brad sees this and chimes in. If not, I'll
try to remember to ask him about it on Monday.
HTH,
David
It appears to be resolved w.r.t. the current *source* directory when
you do not give the full path, and since xyz.dat does not actually
exist in the source dir, there's no way we can know that it is
supposed to be a symlink.
But get_filename_component has to work with non-existing files since
some people need that simply to compute where files should go, or what
other file's base names should be based on CMake variables alone...
Hope that explains it better.
Yes, it does; thanks for straightening this out. Actually, it's rather
obvious that the ABSOLUTE/REALPATH clauses of GET_FILENAME_COMPONENT()
do need a reference point, but perhaps, one should document explicitly
that it's CMAKE_CURRENT_SOURCE_DIR, whereas CMAKE_CURRENT_BINARY_DIR
won't be taken into account. Elsewhere, CMake behaves differently.
Is it CMAKE_CURRENT_SOURCE_DIR? Or is it the current working directory
of the cmake process, which happens to be CMAKE_CURRENT_SOURCE_DIR
when you make the call ...?
Because of questions like these, I asked for refined documentation. ;)
AFAICS from the source code, a relative path is evaluated w.r.t. CMAKE_
CURRENT_SOURCE_DIR only. Anyway, the ABSOLUTE clause has made me think
that it is mainly meant to be used on relative paths, and if it is to
work on non-existing files, too, it needs a single reference point to
evaluate against. Actually, such facts should be mentioned in the docs
since they are essential if ABSOLUTE/REALPATH are to be used correctly.
I know it's *possible* to use non-full paths in many contexts within
CMake and still get the results you expect, but because of little
nuggets like this, ...
... I always, always, always use full paths anyway, unconditionally. [...]
With ADD_EXECUTABLE() and ADD_LIBRARY(), too? ;-) But seriously...
Yes, even with them. Exception: when I'm editing a
Re: [CMake] How not to copy a link
On 01/07/2012 03:52 PM, David Cole wrote:
On Sat, Jan 7, 2012 at 9:47 AM, David Cole david.c...@kitware.com wrote:
On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling mhertl...@online.de
wrote:
On 01/06/2012 07:51 PM, Kevin Burge wrote:
Thanks David. These are external libraries built outside of CMake,
without CMake, not imported via any of the import capabilities of cmake,
and that need to be installed alongside my CMake built files. I think
I'm just going to do the install with the rename. Requires me to be
more explicit, but, it's not like it changes all that frequently.
Isn't it sufficient to copy such SONAME symlinks as they are, along with
the actual library files, of course? Having a symlink from the SONAME to
the library file is a basic mean of the ABI management on platforms with
advanced - ;-) - support of shared libraries. Besides, these symlinks
are automatically created by ldconfig when the latter processes the
directory.
Anyway, w.r.t. your initial question, I'd usually suggest to use the
GET_FILENAME_COMPONENT(... REALPATH) command on the symlink prior
to the INSTALL() command, but it seems to not work as expected:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
touch xyz.dat.0)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
create_symlink xyz.dat.0 xyz.dat)
GET_FILENAME_COMPONENT(XYZ xyz.dat REALPATH)
MESSAGE(XYZ: ${XYZ})
Due to the documentation of GET_FILENAME_COMPONENT(... REALPATH),
... the full path with *all* symlinks resolved (REALPATH).
I'd expect to see
XYZ: .../xyz.dat.0
instead of
XYZ: .../xyz.dat
Do I misunderstand GET_FILENAME_COMPONENT() in respect thereof?
Regards,
Michael
On 01/06/12 12:45, David Cole wrote:
Have you considered setting the VERSION and SOVERSION target
properties on your libraries instead of doing the symlinks yourself?
CMake will build and install the symlinks automatically for you on
platforms where they are supported if you set these target properties.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION
(Or was that just an example, and you need to do this with other
symlink files that are not simply the version symlinks for a
library...?)
HTH,
David
--
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
It works if you use:
GET_FILENAME_COMPONENT(XYZ ${CMAKE_CURRENT_BINARY_DIR}/xyz.dat REALPATH)
I'm not 100% sure if the behavior is expected to be defined for
non-full paths. Hopefully Brad sees this and chimes in. If not, I'll
try to remember to ask him about it on Monday.
HTH,
David
It appears to be resolved w.r.t. the current *source* directory when
you do not give the full path, and since xyz.dat does not actually
exist in the source dir, there's no way we can know that it is
supposed to be a symlink.
But get_filename_component has to work with non-existing files since
some people need that simply to compute where files should go, or what
other file's base names should be based on CMake variables alone...
Hope that explains it better.
Yes, it does; thanks for straightening this out. Actually, it's rather
obvious that the ABSOLUTE/REALPATH clauses of GET_FILENAME_COMPONENT()
do need a reference point, but perhaps, one should document explicitly
that it's CMAKE_CURRENT_SOURCE_DIR, whereas CMAKE_CURRENT_BINARY_DIR
won't be taken into account. Elsewhere, CMake behaves differently.
I know it's *possible* to use non-full paths in many contexts within
CMake and still get the results you expect, but because of little
nuggets like this, ...
... I always, always, always use full paths anyway, unconditionally. [...]
With ADD_EXECUTABLE() and ADD_LIBRARY(), too? ;-) But seriously...
[...] I
always recommend to everyone that they also adopt this CMake best
practice of referring to files by their full path names whenever
possible. It eliminates confusion, ambiguity and unintended mistaken
results -- and is 100% absolutely worth the effort.
Definitely agreed, but there're some commands which are typically used
with relative paths, although it's not explicitly documented how they
behave in this respect. Notable examples are the already mentioned
ADD_EXECUTABLE/LIBRARY() or SET_SOURCE_FILES_PROPERTIES() - IMO, the
latter should behave in the same manner as the formers, so one can use
the same source file specifications. Perhaps, one could add a few lines
to the documentation in order to clarify for which commands/properties/
etc. a relative path does behave well, e.g. like for ADD_SUBDIRECTORY().
Regards,
Michael
--
Re: [CMake] How not to copy a link
On Wed, Jan 11, 2012 at 10:10 AM, Michael Hertling mhertl...@online.de wrote:
On 01/07/2012 03:52 PM, David Cole wrote:
On Sat, Jan 7, 2012 at 9:47 AM, David Cole david.c...@kitware.com wrote:
On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling mhertl...@online.de
wrote:
On 01/06/2012 07:51 PM, Kevin Burge wrote:
Thanks David. These are external libraries built outside of CMake,
without CMake, not imported via any of the import capabilities of cmake,
and that need to be installed alongside my CMake built files. I think
I'm just going to do the install with the rename. Requires me to be
more explicit, but, it's not like it changes all that frequently.
Isn't it sufficient to copy such SONAME symlinks as they are, along with
the actual library files, of course? Having a symlink from the SONAME to
the library file is a basic mean of the ABI management on platforms with
advanced - ;-) - support of shared libraries. Besides, these symlinks
are automatically created by ldconfig when the latter processes the
directory.
Anyway, w.r.t. your initial question, I'd usually suggest to use the
GET_FILENAME_COMPONENT(... REALPATH) command on the symlink prior
to the INSTALL() command, but it seems to not work as expected:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
touch xyz.dat.0)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
create_symlink xyz.dat.0 xyz.dat)
GET_FILENAME_COMPONENT(XYZ xyz.dat REALPATH)
MESSAGE(XYZ: ${XYZ})
Due to the documentation of GET_FILENAME_COMPONENT(... REALPATH),
... the full path with *all* symlinks resolved (REALPATH).
I'd expect to see
XYZ: .../xyz.dat.0
instead of
XYZ: .../xyz.dat
Do I misunderstand GET_FILENAME_COMPONENT() in respect thereof?
Regards,
Michael
On 01/06/12 12:45, David Cole wrote:
Have you considered setting the VERSION and SOVERSION target
properties on your libraries instead of doing the symlinks yourself?
CMake will build and install the symlinks automatically for you on
platforms where they are supported if you set these target properties.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION
(Or was that just an example, and you need to do this with other
symlink files that are not simply the version symlinks for a
library...?)
HTH,
David
--
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
It works if you use:
GET_FILENAME_COMPONENT(XYZ ${CMAKE_CURRENT_BINARY_DIR}/xyz.dat REALPATH)
I'm not 100% sure if the behavior is expected to be defined for
non-full paths. Hopefully Brad sees this and chimes in. If not, I'll
try to remember to ask him about it on Monday.
HTH,
David
It appears to be resolved w.r.t. the current *source* directory when
you do not give the full path, and since xyz.dat does not actually
exist in the source dir, there's no way we can know that it is
supposed to be a symlink.
But get_filename_component has to work with non-existing files since
some people need that simply to compute where files should go, or what
other file's base names should be based on CMake variables alone...
Hope that explains it better.
Yes, it does; thanks for straightening this out. Actually, it's rather
obvious that the ABSOLUTE/REALPATH clauses of GET_FILENAME_COMPONENT()
do need a reference point, but perhaps, one should document explicitly
that it's CMAKE_CURRENT_SOURCE_DIR, whereas CMAKE_CURRENT_BINARY_DIR
won't be taken into account. Elsewhere, CMake behaves differently.
Is it CMAKE_CURRENT_SOURCE_DIR? Or is it the current working directory
of the cmake process, which happens to be CMAKE_CURRENT_SOURCE_DIR
when you make the call ...?
I know it's *possible* to use non-full paths in many contexts within
CMake and still get the results you expect, but because of little
nuggets like this, ...
... I always, always, always use full paths anyway, unconditionally. [...]
With ADD_EXECUTABLE() and ADD_LIBRARY(), too? ;-) But seriously...
Yes, even with them. Exception: when I'm editing a CMakeLists file
that pre-dates my involvement, and I'm just making an edit to blend in
with what's there and working already...
And especially with add_custom_command, add_custom_target,
execute_process calls. And file DEPENDS clauses for anything.
[...] I
always recommend to everyone that they also adopt this CMake best
practice of referring to files by their full path names whenever
possible. It eliminates confusion, ambiguity and unintended mistaken
results -- and is 100% absolutely worth the effort.
Definitely agreed, but there're some
Re: [CMake] How not to copy a link
On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling mhertl...@online.de wrote:
On 01/06/2012 07:51 PM, Kevin Burge wrote:
Thanks David. These are external libraries built outside of CMake,
without CMake, not imported via any of the import capabilities of cmake,
and that need to be installed alongside my CMake built files. I think
I'm just going to do the install with the rename. Requires me to be
more explicit, but, it's not like it changes all that frequently.
Isn't it sufficient to copy such SONAME symlinks as they are, along with
the actual library files, of course? Having a symlink from the SONAME to
the library file is a basic mean of the ABI management on platforms with
advanced - ;-) - support of shared libraries. Besides, these symlinks
are automatically created by ldconfig when the latter processes the
directory.
Anyway, w.r.t. your initial question, I'd usually suggest to use the
GET_FILENAME_COMPONENT(... REALPATH) command on the symlink prior
to the INSTALL() command, but it seems to not work as expected:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
touch xyz.dat.0)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
create_symlink xyz.dat.0 xyz.dat)
GET_FILENAME_COMPONENT(XYZ xyz.dat REALPATH)
MESSAGE(XYZ: ${XYZ})
Due to the documentation of GET_FILENAME_COMPONENT(... REALPATH),
... the full path with *all* symlinks resolved (REALPATH).
I'd expect to see
XYZ: .../xyz.dat.0
instead of
XYZ: .../xyz.dat
Do I misunderstand GET_FILENAME_COMPONENT() in respect thereof?
Regards,
Michael
On 01/06/12 12:45, David Cole wrote:
Have you considered setting the VERSION and SOVERSION target
properties on your libraries instead of doing the symlinks yourself?
CMake will build and install the symlinks automatically for you on
platforms where they are supported if you set these target properties.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION
(Or was that just an example, and you need to do this with other
symlink files that are not simply the version symlinks for a
library...?)
HTH,
David
--
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
It works if you use:
GET_FILENAME_COMPONENT(XYZ ${CMAKE_CURRENT_BINARY_DIR}/xyz.dat REALPATH)
I'm not 100% sure if the behavior is expected to be defined for
non-full paths. Hopefully Brad sees this and chimes in. If not, I'll
try to remember to ask him about it on Monday.
HTH,
David
--
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
Re: [CMake] How not to copy a link
On Sat, Jan 7, 2012 at 9:47 AM, David Cole david.c...@kitware.com wrote:
On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling mhertl...@online.de wrote:
On 01/06/2012 07:51 PM, Kevin Burge wrote:
Thanks David. These are external libraries built outside of CMake,
without CMake, not imported via any of the import capabilities of cmake,
and that need to be installed alongside my CMake built files. I think
I'm just going to do the install with the rename. Requires me to be
more explicit, but, it's not like it changes all that frequently.
Isn't it sufficient to copy such SONAME symlinks as they are, along with
the actual library files, of course? Having a symlink from the SONAME to
the library file is a basic mean of the ABI management on platforms with
advanced - ;-) - support of shared libraries. Besides, these symlinks
are automatically created by ldconfig when the latter processes the
directory.
Anyway, w.r.t. your initial question, I'd usually suggest to use the
GET_FILENAME_COMPONENT(... REALPATH) command on the symlink prior
to the INSTALL() command, but it seems to not work as expected:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
touch xyz.dat.0)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
create_symlink xyz.dat.0 xyz.dat)
GET_FILENAME_COMPONENT(XYZ xyz.dat REALPATH)
MESSAGE(XYZ: ${XYZ})
Due to the documentation of GET_FILENAME_COMPONENT(... REALPATH),
... the full path with *all* symlinks resolved (REALPATH).
I'd expect to see
XYZ: .../xyz.dat.0
instead of
XYZ: .../xyz.dat
Do I misunderstand GET_FILENAME_COMPONENT() in respect thereof?
Regards,
Michael
On 01/06/12 12:45, David Cole wrote:
Have you considered setting the VERSION and SOVERSION target
properties on your libraries instead of doing the symlinks yourself?
CMake will build and install the symlinks automatically for you on
platforms where they are supported if you set these target properties.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION
(Or was that just an example, and you need to do this with other
symlink files that are not simply the version symlinks for a
library...?)
HTH,
David
--
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
It works if you use:
GET_FILENAME_COMPONENT(XYZ ${CMAKE_CURRENT_BINARY_DIR}/xyz.dat REALPATH)
I'm not 100% sure if the behavior is expected to be defined for
non-full paths. Hopefully Brad sees this and chimes in. If not, I'll
try to remember to ask him about it on Monday.
HTH,
David
It appears to be resolved w.r.t. the current *source* directory when
you do not give the full path, and since xyz.dat does not actually
exist in the source dir, there's no way we can know that it is
supposed to be a symlink.
But get_filename_component has to work with non-existing files since
some people need that simply to compute where files should go, or what
other file's base names should be based on CMake variables alone...
Hope that explains it better.
I know it's *possible* to use non-full paths in many contexts within
CMake and still get the results you expect, but because of little
nuggets like this, ...
... I always, always, always use full paths anyway, unconditionally. I
always recommend to everyone that they also adopt this CMake best
practice of referring to files by their full path names whenever
possible. It eliminates confusion, ambiguity and unintended mistaken
results -- and is 100% absolutely worth the effort.
Cheers,
David
--
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
[CMake] How not to copy a link
I'm trying to copy a file that is a link to another file, but I want the file to be copied, not the link itself. Historically, I've resorted to putting the real file as the source, and then using RENAME to rename the file, which puts more detail into my install commands than I'd like. Example: where libfoo.so.1.0 - libfoo.so.1.0.8: i.e. instead of: install (FILES libfoo.so.1.0.8 DESTINATION lib RENAME libfoo.so.1.0) I'd like to just do: install (FILES libfoo.so.1.0 DESTINATION lib) I've had little success search the cmake source and documentation and google. Thanks, Kevin -- 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
Re: [CMake] How not to copy a link
Have you considered setting the VERSION and SOVERSION target properties on your libraries instead of doing the symlinks yourself? CMake will build and install the symlinks automatically for you on platforms where they are supported if you set these target properties. http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION (Or was that just an example, and you need to do this with other symlink files that are not simply the version symlinks for a library...?) HTH, David On Fri, Jan 6, 2012 at 11:30 AM, Kevin Burge kevin.bu...@systemware.com wrote: I'm trying to copy a file that is a link to another file, but I want the file to be copied, not the link itself. Historically, I've resorted to putting the real file as the source, and then using RENAME to rename the file, which puts more detail into my install commands than I'd like. Example: where libfoo.so.1.0 - libfoo.so.1.0.8: i.e. instead of: install (FILES libfoo.so.1.0.8 DESTINATION lib RENAME libfoo.so.1.0) I'd like to just do: install (FILES libfoo.so.1.0 DESTINATION lib) I've had little success search the cmake source and documentation and google. Thanks, Kevin -- 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 -- 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
Re: [CMake] How not to copy a link
Thanks David. These are external libraries built outside of CMake, without CMake, not imported via any of the import capabilities of cmake, and that need to be installed alongside my CMake built files. I think I'm just going to do the install with the rename. Requires me to be more explicit, but, it's not like it changes all that frequently. On 01/06/12 12:45, David Cole wrote: Have you considered setting the VERSION and SOVERSION target properties on your libraries instead of doing the symlinks yourself? CMake will build and install the symlinks automatically for you on platforms where they are supported if you set these target properties. http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION (Or was that just an example, and you need to do this with other symlink files that are not simply the version symlinks for a library...?) HTH, David -- 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
Re: [CMake] How not to copy a link
On 01/06/2012 07:51 PM, Kevin Burge wrote:
Thanks David. These are external libraries built outside of CMake,
without CMake, not imported via any of the import capabilities of cmake,
and that need to be installed alongside my CMake built files. I think
I'm just going to do the install with the rename. Requires me to be
more explicit, but, it's not like it changes all that frequently.
Isn't it sufficient to copy such SONAME symlinks as they are, along with
the actual library files, of course? Having a symlink from the SONAME to
the library file is a basic mean of the ABI management on platforms with
advanced - ;-) - support of shared libraries. Besides, these symlinks
are automatically created by ldconfig when the latter processes the
directory.
Anyway, w.r.t. your initial question, I'd usually suggest to use the
GET_FILENAME_COMPONENT(... REALPATH) command on the symlink prior
to the INSTALL() command, but it seems to not work as expected:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
touch xyz.dat.0)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
create_symlink xyz.dat.0 xyz.dat)
GET_FILENAME_COMPONENT(XYZ xyz.dat REALPATH)
MESSAGE(XYZ: ${XYZ})
Due to the documentation of GET_FILENAME_COMPONENT(... REALPATH),
... the full path with *all* symlinks resolved (REALPATH).
I'd expect to see
XYZ: .../xyz.dat.0
instead of
XYZ: .../xyz.dat
Do I misunderstand GET_FILENAME_COMPONENT() in respect thereof?
Regards,
Michael
On 01/06/12 12:45, David Cole wrote:
Have you considered setting the VERSION and SOVERSION target
properties on your libraries instead of doing the symlinks yourself?
CMake will build and install the symlinks automatically for you on
platforms where they are supported if you set these target properties.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION
(Or was that just an example, and you need to do this with other
symlink files that are not simply the version symlinks for a
library...?)
HTH,
David
--
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
