[CMake] portable way of linking (external) libs statically/dynamically/for dlopen
Hi. I've always thought one of the main objectives of cmake was being portable, right? So I was looking for a way to let the user (i.e. the person building a project) choose how he wan't to link each external library (i.e. not the ones built as targets by my project), depending on what that lib supports and (when my own code supports it:) dynamically loaded via e.g. dlopen. But it seems that I cannot even tell CMake (in a portable way) that it should use static or dynamic linking for some external lib (not to talk about the core libs like libc or libstdc++). Of course I can work around this any manually search for e.g. .so and .a files... but that woudln't be portable anymore... not to talk about different linkage options per linker... so ideally CMake should (IMHO) take care of all this (for each supported platform/linker). Am I missing something? Or is that just som major deficiency in the portable-part? Cheers, Phil -- 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] portable way of linking (external) libs statically/dynamically/for dlopen
On Mon, Apr 29, 2013 at 8:30 PM, Ian Monroe i...@monroe.nu wrote: Static linking of external libraries is just a weird thing to do. And I thought this wasn’t lkml, where it’s perfectly fine that people, instead of answering the question (if they choose to answer at all) tell you your use case would be invalid ;-) Well I'm perfectly aware of the advantages/disadvantages of static linking... but there quite some circumstances where users may prefer it over dynamic linking :) Cheers! -- 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] portable way of linking (external) libs statically/dynamically/for dlopen
On Mon, Apr 29, 2013 at 10:36 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: If cmake finds the static version of the library, it should properly use that one. I thought it would use the shared one per default? Making cmake find the static version instead of the dynamic version is kind of hard, AFAIK the only way to do this is to give the full filename of the static lib. In other words: not portable. :( -- 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] portable way of linking (external) libs statically/dynamically/for dlopen
On Mon, Apr 29, 2013 at 10:40 PM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com wrote: For example: https://github.com/commontk/CTK/blob/ac13c32312c9160190b80bd3a03d012782eff40c/Libs/Core/CMake/ctkMacroBFDCheck.cmake#L33-43 I'm not sure whether I understand this correctly, or whether it is what I want ;) You still seem to hardcode the static library name (= not portable) -- 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] portable way of linking (external) libs statically/dynamically/for dlopen
On Tue, Apr 30, 2013 at 1:54 AM, J Decker d3c...@gmail.com wrote:
lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_SHARED_LIBRARY_PREFIX}c${CMAKE_SHARED_LIBRARY_SUFFIX}
or
lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_STATIC_LIBRARY_PREFIX}c${CMAKE_STATIC_LIBRARY_SUFFIX}
to choose lib[64]/libc.so or lib[64]/libc.a (or it would generate
c.dll/c.lib for windows type compilers)
But, although you can generate portable projects that target lots of
platforms, the scripts still have to have things like
if( WIN32 )
if( UNIX )
etc...
Well exactly this is what I don't wan to do as it's not portable...
_I_ (the developer) need to take care on any possible platorm, it's
library naming conventions and possibly also on any compiler/linker
suite I want to support...
If the responsibility for this falls back to me, I can also build via
shell script (more or less).
What I'd like to have is:
1) My CMakeLists checks for all dependencies (e.g. lib foo) using the
CMakes functions for that.
These functions should tell me which versions were found (i.e. static
or shared).
2) Depending on (1) I set CMake options cache with reasonable defaults
(i.e. in most cases this will be link lib foo dynamic) for each lib
foo.
For some I might even offer to use dlopen(), depending on whether my
sources support this.
3) The user can then chance that settings per lib in the cache as he likes.
4) When I say target_link_library... I want to set some flag (static
vs. shared) depending on what was chosen in (3) (or not link at all in
case of dlopen()),
Everything else, platform naming conventions, compiler/linker options,
should happen automatically (for all supported platforms +
compilter/linker suites)... that would be portability.
Cheers!
--
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
