Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen
Ya; additional generators might be nice 'static runtime' or 'dynamic runtime' but that's only just the C runtime, and doesn't account for the uncounted other libraries you may also depend on. Although I suppose it would make sense that if it was 'static' that all other related things should also be static; instead of choosing specifically each one on a case-by-case basis. Or maybe a different CMAKE_BUILD_TYPE .. debug, debug_static, etc... maybe that's an option to add_executable( target STATIC sources ) (static works for add_library() to choose a specific mode) On Mon, Apr 29, 2013 at 6:44 PM, Philippe Cerfon philc...@gmail.com wrote: 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
[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 11:13 AM, Philippe Cerfon philc...@gmail.comwrote: 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? Static linking of external libraries is just a weird thing to do. Ian -- 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 Monday 29 April 2013, Philippe Cerfon wrote: 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? If cmake finds the static version of the library, it should properly use that one. 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. Alex -- 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
For example: https://github.com/commontk/CTK/blob/ac13c32312c9160190b80bd3a03d012782eff40c/Libs/Core/CMake/ctkMacroBFDCheck.cmake#L33-43 Hth Jc On Mon, Apr 29, 2013 at 4:36 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Monday 29 April 2013, Philippe Cerfon wrote: 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? If cmake finds the static version of the library, it should properly use that one. 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. Alex -- 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 -- +1 919 869 8849 -- 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
hard coded names aren't so bad, since they can be composed of dynamic peices... 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... On Mon, Apr 29, 2013 at 2:38 PM, Philippe Cerfon philc...@gmail.com wrote: 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 -- 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