Re: [CMake] target_link_libraries: prefer static to dynamic
On Monday 28 December 2009, Bill Hoffman wrote: Pau Garcia i Quiles wrote: I'm using CMake 2.8.0 on Linux. Yes, Michael is right: I want it to happen automagically. That was the whole point of this thread :-) OK, well the thread has a very bad subject then It should be force find_library to choose static over shared. This really has nothing to do with target_link_libraries at all. When given a static library target_link_libraries will use it. it would be really nice if this was possible. I think this must be more or less the one remaining missing feature of cmake ;-) The next part is how to change find_library to find only static libraries. If you really wanted this now, you could implement it in cmake code for your project using find_file and only looking for .a libraries if UNIX is on. For windows it would be much harder to implement as there is no way to tell the difference from the shared and static as they both end in .lib. Isn't there some binutil which can tell what kind of library some .lib is ? Or maybe every dll (and that way the accompanying lib) has some functions which only dlls have ? Or maybe they references some special functions which maybe could be checked with something like nm ? 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] target_link_libraries: prefer static to dynamic
On Sun, Jan 3, 2010 at 2:26 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Isn't there some binutil which can tell what kind of library some .lib is ? Or maybe every dll (and that way the accompanying lib) has some functions which only dlls have ? Or maybe they references some special functions which maybe could be checked with something like nm ? If I recall correctly we discussed this a long time ago and there were some dll specific symbols present in the accompanying import library that weren't there in the static library. -- Philip Lowman ___ 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] target_link_libraries: prefer static to dynamic
On Mon, 28 Dec 2009 12:29:05 +0100, Pau Garcia i Quiles pgqui...@elpauer.org wrote: I'm using CMake 2.8.0 on Linux. Yes, Michael is right: I want it to happen automagically. That was the whole point of this thread :-) I would argue that FindXXX.cmake is the wrong place for the decision to be made since I may want my project to link different targets differently (as with pkg-config's --static option). Jed ___ 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] target_link_libraries: prefer static to dynamic
On 30. Dec, 2009, at 17:32 , Jed Brown wrote: On Mon, 28 Dec 2009 12:29:05 +0100, Pau Garcia i Quiles pgqui...@elpauer.org wrote: I'm using CMake 2.8.0 on Linux. Yes, Michael is right: I want it to happen automagically. That was the whole point of this thread :-) I would argue that FindXXX.cmake is the wrong place for the decision to be made since I may want my project to link different targets differently (as with pkg-config's --static option). Jed That would be a rather unusual choice (IMHO). What would be your preferred way of doing this with 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] target_link_libraries: prefer static to dynamic
On Wed, 30 Dec 2009 17:51:29 +0100, Michael Wild them...@gmail.com wrote: On 30. Dec, 2009, at 17:32 , Jed Brown wrote: On Mon, 28 Dec 2009 12:29:05 +0100, Pau Garcia i Quiles pgqui...@elpauer.org wrote: I'm using CMake 2.8.0 on Linux. Yes, Michael is right: I want it to happen automagically. That was the whole point of this thread :-) I would argue that FindXXX.cmake is the wrong place for the decision to be made since I may want my project to link different targets differently (as with pkg-config's --static option). Jed That would be a rather unusual choice (IMHO). What would be your preferred way of doing this with CMake? I realize it is much different than how CMake currently operates (where libraries are a lower-level concept than in e.g. pkg-config), but I don't believe it's a strange thing to want a project to link different targets differently. Jed ___ 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] target_link_libraries: prefer static to dynamic
On 30. Dec, 2009, at 18:02 , Jed Brown wrote: On Wed, 30 Dec 2009 17:51:29 +0100, Michael Wild them...@gmail.com wrote: On 30. Dec, 2009, at 17:32 , Jed Brown wrote: On Mon, 28 Dec 2009 12:29:05 +0100, Pau Garcia i Quiles pgqui...@elpauer.org wrote: I'm using CMake 2.8.0 on Linux. Yes, Michael is right: I want it to happen automagically. That was the whole point of this thread :-) I would argue that FindXXX.cmake is the wrong place for the decision to be made since I may want my project to link different targets differently (as with pkg-config's --static option). Jed That would be a rather unusual choice (IMHO). What would be your preferred way of doing this with CMake? I realize it is much different than how CMake currently operates (where libraries are a lower-level concept than in e.g. pkg-config), but I don't believe it's a strange thing to want a project to link different targets differently. Jed I don't think this will ever work easily, since the user can (and should) be able to specify a specific library in the cache. Your request would require that every library, for every target, gets a separate cache entry. If you have more than just ~10 targets, the number of cache entries will just explode and become very confusing to the user. Worse, you might actually run into serious trouble due to transitive linking (say target library A links against the external library foo, and B links against both A and also foo. Now, if the user doesn't know that the author of the CMakeLists.txt made a mistake, and choses different versions of the foo library for A and B, all hell breaks lose... Your right, in old-school autohell projects using pkg-config it is possible to do such things, but then the user had no option of overriding that choice. Just my 2c. Michael ___ 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] target_link_libraries: prefer static to dynamic
On 28. Dec, 2009, at 5:38 , Bill Hoffman wrote:
Pau Garcia i Quiles wrote:
On Sun, Dec 27, 2009 at 6:26 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
Pau Garcia i Quiles wrote:
Hello,
I think this has already been discussed and the answer is negative but
still: when I do target_link_libraries to an external library (for
instance, my application needs to link to sqlite), is it possible to
tell CMake to link to the static version of sqlite instead of the
dynamic version?
For instance, in Debian the libsqlite3-dev package contains both the
static and the dynamic versions of the library and they have the very
same name:
/usr/lib/libsqlite3.a
/usr/lib/libsqlite3.so
( http://packages.debian.org/sid/i386/libsqlite3-dev/filelist )
Is this feature going to be implemented any time soon? I have not
looked at the sources for target_link_libraries but at first sight it
doesn't look difficult to add something like
static;optimized;libsqlite3.a;dynamic;optimized;libsqlite3.so.
There's the problem of find_library on Windows confusing the .lib as
the import for a .dll with a static .lib library but IIRC it's
possible to detect that.
If you use the full path then it should work fine. find_library will always
return the full path. So if you do target_link_libraries(foo ${SQLITELIB})
where SQLITELIB = /usr/lib/libswlite3.a then it will work just fine.
That will not work in the case I was describing, where you have both
the shared and the static versions of the library installed. Futher,
it would be even worse if both the static and the shared versions of
the library are installed but in different paths, because you would
depend on what path is searched first.
As I said if you install libsqlite3-dev on a Debian-based distro, it
will install both /usr/lib/libsqlite3.a and /usr/lib/libsqlite3.so.
How can I be sure find_library will find the static version before the
dynamic one. What happens if the path to the static library is
searched after the path to the shared library?
What version of CMake are you using? This should work... As of 2.6.2 (I
think...) CMake uses full paths to libraries, see policy CMP0003:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#policy:CMP0003. It does
not matter if there are two libraries in the same directory. There is no way
to force find_library to find the static one. However, if you tell CMake to
link to a full path to /usr/lib/libsqlite3.a, it should link to
/usr/lib/libsqlite3.a even if /usr/lib/libsqlite3.so exists.
-Bill
I think there is a misunderstanding... Pau wants it to happen automagically,
whereas Bill is referring to overriding the automatic choice manually in the
CMakeCache.txt file (be it by using -D flags, editing the file, using ccmake or
cmake-gui or a cache-initialization file).
Michael
___
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] target_link_libraries: prefer static to dynamic
On 27. Dec, 2009, at 23:30 , Pau Garcia i Quiles wrote: On Sun, Dec 27, 2009 at 10:16 PM, Michael Wild them...@gmail.com wrote: On 27. Dec, 2009, at 20:41 , Pau Garcia i Quiles wrote: On Sun, Dec 27, 2009 at 10:59 AM, Michael Wild them...@gmail.com wrote: On 26. Dec, 2009, at 17:53 , Pau Garcia i Quiles wrote: Hello, I think this has already been discussed and the answer is negative but still: when I do target_link_libraries to an external library (for instance, my application needs to link to sqlite), is it possible to tell CMake to link to the static version of sqlite instead of the dynamic version? For instance, in Debian the libsqlite3-dev package contains both the static and the dynamic versions of the library and they have the very same name: /usr/lib/libsqlite3.a /usr/lib/libsqlite3.so ( http://packages.debian.org/sid/i386/libsqlite3-dev/filelist ) Is this feature going to be implemented any time soon? I have not looked at the sources for target_link_libraries but at first sight it doesn't look difficult to add something like static;optimized;libsqlite3.a;dynamic;optimized;libsqlite3.so. There's the problem of find_library on Windows confusing the .lib as the import for a .dll with a static .lib library but IIRC it's possible to detect that. Perhaps a variable CMAKE_FIND_STATIC with the possible values FIRST LAST, ONLY and NEVER, similar to CMAKE_FIND_FRAMEWORK, would fit the bill? No, it won't. If my application links to two libraries, I may want to link statically to libA but dynamically to libB. But then, on Debian a static version of sqlite3 is available, but not on Mac OS X (that is, without compiling it yourself). What should be the behavior there? Perhaps this could be expanded to optional options FIND_STATIC of find_library and find_package? Besides, the variable IS enough: set(CMAKE_FIND_STATIC FIRST) find_library(SQLITE_LIBRARY sqlite3) set(CMAKE_FIND_STATIC LAST) find_library(OTHER_LIBRARY other) Instead of having CMAKE_FIND_STATIC, CMAKE_FIND_FRAMEWORK, CMAKE_FIND_APPBUNDLE, etc, those could be replaced with something like this in find_library: find_library( VAR name | NAMES name1 [name2 ...] [...] VARIANT variant1 [variant2 ...] ) Where variant1, variant2, etc would be shared static framework bundle by default. That'd mean find_libraries searches for shared, static, framework and bundle in that order. With my proposal for find_library, and the one I made in the first e-mail of this thread, if I do: find_library( SQLITE3_LIBRARY_RELEASE sqlite3 VARIANT static shared ) I'd have: SQLITE3_LIBRARY_RELEASE=static;release;/usr/lib/libsqlite3.a But if I do: find_library( SQLITE3_LIBRARY_RELEASE sqlite3 VARIANT shared static ) I'd have: SQLITE3_LIBRARY_RELEASE=share;release;/usr/lib/libsqlite3.so I. e. I'm expressing preference: in the first case I'm saying I'd like to find a static version of sqlite3 but if it's not available, give me the shared version. I could also look for the static version only: find_library( SQLITE3_LIBRARY_RELEASE sqlite3 VARIANT static ) or the shared one: find_library( SQLITE3_LIBRARY_RELEASE sqlite3 VARIANT shared ) Meaning: in the first case I want to find a static version of sqlite3 and fail if it's not available. Neither of those should not be the default, though. So for instance if I do: find_library( SQLITE3_LIBRARY_RELEASE sqlite3 ) That'd would be equivalent to: find_library( SQLITE3_LIBRARY_RELEASE sqlite3 VARIANT shared static framework bundle ) That sounds doable to me. However, you'd need a mechanism to express the same preference when calling find_package and then have find_package communicate that to find_library. Not sure how fine-grained the control should be for FindXXX.cmake modules that find more than one library (or call another FindYYY.cmake internally). Michael ___ 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] target_link_libraries: prefer static to dynamic
What version of CMake are you using? This should work... As of 2.6.2 (I think...) CMake uses full paths to libraries, see policy CMP0003: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#policy:CMP0003. It does not matter if there are two libraries in the same directory. There is no way to force find_library to find the static one. However, if you tell CMake to link to a full path to /usr/lib/libsqlite3.a, it should link to /usr/lib/libsqlite3.a even if /usr/lib/libsqlite3.so exists. -Bill I think there is a misunderstanding... Pau wants it to happen automagically, whereas Bill is referring to overriding the automatic choice manually in the CMakeCache.txt file (be it by using -D flags, editing the file, using ccmake or cmake-gui or a cache-initialization file). I'm using CMake 2.8.0 on Linux. Yes, Michael is right: I want it to happen automagically. That was the whole point of this thread :-) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ 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] target_link_libraries: prefer static to dynamic
That sounds doable to me. However, you'd need a mechanism to express the same
preference when calling find_package and then have find_package communicate
that to find_library. Not sure how fine-grained
the control should be for FindXXX.cmake modules that find more than one
library (or call another FindYYY.cmake internally).
The very same syntax should work for find_package: find_package( XXX
VARIANT static shared ). Inside FindXXX.cmake you'd do something like:
IF( XXX_FIND_VARIANTS )
FIND_LIBRARY( xxx VARIANTS ${XXX_FIND_VARIANTS} )
ELSE( XXX_FIND_VARIANTS )
FIND_LIBRARY( xxx )
ENDIF( XXX_FIND_VARIANTS )
Or, even better, one of these three solutions could be adopted to
avoid the 'if':
* Make XXX_FIND_VARIANTS contain VARIANTS static shared ... instead
of just static shared That way, in FindXXX.cmake you'd do:
FIND_LIBRARY( xxx ${XXX_FIND_VARIANTS} )
If find_package was called without the VARIANTS parameter, that'd
resolve to FIND_LIBRARY( xxx )
* Make CMake automagically construct XXX_FIND_VARIANTS with the
default values (shared static ... or whatever Kitware considers
sensible). I. e. inside find_package, XXX_FIND_VARIANTS would always
exist. If it was overriden by the FindXXX.cmake author, it'd have the
overriden value. If it wasn't overriden by the FindXXX.cmake author,
it'd have the default value. Again, in FindXXX.cmake you'd only do:
FIND_LIBRARY( xxx ${XXX_FIND_VARIANTS} )
* Make find_library always consider XXX_FIND_VARIANTS (a different
name, such as xxx_FIND_LIBRARY_VARIANTS, would probably be better to
avoid confusion with modules' variables) if it exists, without the
need for a new parameter to find_library/find_package. Pros: every
CMake module gains support for finding static, shared, frameworks,
etc. Cons: very intrusive.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
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] target_link_libraries: prefer static to dynamic
On 28. Dec, 2009, at 12:40 , Pau Garcia i Quiles wrote:
That sounds doable to me. However, you'd need a mechanism to express the
same preference when calling find_package and then have find_package
communicate that to find_library. Not sure how fine-grained
the control should be for FindXXX.cmake modules that find more than one
library (or call another FindYYY.cmake internally).
The very same syntax should work for find_package: find_package( XXX
VARIANT static shared ). Inside FindXXX.cmake you'd do something like:
IF( XXX_FIND_VARIANTS )
FIND_LIBRARY( xxx VARIANTS ${XXX_FIND_VARIANTS} )
ELSE( XXX_FIND_VARIANTS )
FIND_LIBRARY( xxx )
ENDIF( XXX_FIND_VARIANTS )
Or, even better, one of these three solutions could be adopted to
avoid the 'if':
* Make XXX_FIND_VARIANTS contain VARIANTS static shared ... instead
of just static shared That way, in FindXXX.cmake you'd do:
FIND_LIBRARY( xxx ${XXX_FIND_VARIANTS} )
If find_package was called without the VARIANTS parameter, that'd
resolve to FIND_LIBRARY( xxx )
* Make CMake automagically construct XXX_FIND_VARIANTS with the
default values (shared static ... or whatever Kitware considers
sensible). I. e. inside find_package, XXX_FIND_VARIANTS would always
exist. If it was overriden by the FindXXX.cmake author, it'd have the
overriden value. If it wasn't overriden by the FindXXX.cmake author,
it'd have the default value. Again, in FindXXX.cmake you'd only do:
FIND_LIBRARY( xxx ${XXX_FIND_VARIANTS} )
* Make find_library always consider XXX_FIND_VARIANTS (a different
name, such as xxx_FIND_LIBRARY_VARIANTS, would probably be better to
avoid confusion with modules' variables) if it exists, without the
need for a new parameter to find_library/find_package. Pros: every
CMake module gains support for finding static, shared, frameworks,
etc. Cons: very intrusive.
I'd go with option 2. I'm still unsure whether it would be desirable to have
more fine grained control, e.g. if FindXXX has multiple find_library calls, or
calls itself find_package internally.
And, of course, somebody would have to implement it... What about compatibility
with CMAKE_FIND_FRAMEWORK?
Michael
___
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] target_link_libraries: prefer static to dynamic
Pau Garcia i Quiles wrote: I'm using CMake 2.8.0 on Linux. Yes, Michael is right: I want it to happen automagically. That was the whole point of this thread :-) OK, well the thread has a very bad subject then It should be force find_library to choose static over shared. This really has nothing to do with target_link_libraries at all. When given a static library target_link_libraries will use it. The next part is how to change find_library to find only static libraries. If you really wanted this now, you could implement it in cmake code for your project using find_file and only looking for .a libraries if UNIX is on. For windows it would be much harder to implement as there is no way to tell the difference from the shared and static as they both end in .lib. -Bill ___ 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] target_link_libraries: prefer static to dynamic
On 26. Dec, 2009, at 17:53 , Pau Garcia i Quiles wrote: Hello, I think this has already been discussed and the answer is negative but still: when I do target_link_libraries to an external library (for instance, my application needs to link to sqlite), is it possible to tell CMake to link to the static version of sqlite instead of the dynamic version? For instance, in Debian the libsqlite3-dev package contains both the static and the dynamic versions of the library and they have the very same name: /usr/lib/libsqlite3.a /usr/lib/libsqlite3.so ( http://packages.debian.org/sid/i386/libsqlite3-dev/filelist ) Is this feature going to be implemented any time soon? I have not looked at the sources for target_link_libraries but at first sight it doesn't look difficult to add something like static;optimized;libsqlite3.a;dynamic;optimized;libsqlite3.so. There's the problem of find_library on Windows confusing the .lib as the import for a .dll with a static .lib library but IIRC it's possible to detect that. Perhaps a variable CMAKE_FIND_STATIC with the possible values FIRST LAST, ONLY and NEVER, similar to CMAKE_FIND_FRAMEWORK, would fit the bill? Michael ___ 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] target_link_libraries: prefer static to dynamic
Pau Garcia i Quiles wrote:
Hello,
I think this has already been discussed and the answer is negative but
still: when I do target_link_libraries to an external library (for
instance, my application needs to link to sqlite), is it possible to
tell CMake to link to the static version of sqlite instead of the
dynamic version?
For instance, in Debian the libsqlite3-dev package contains both the
static and the dynamic versions of the library and they have the very
same name:
/usr/lib/libsqlite3.a
/usr/lib/libsqlite3.so
( http://packages.debian.org/sid/i386/libsqlite3-dev/filelist )
Is this feature going to be implemented any time soon? I have not
looked at the sources for target_link_libraries but at first sight it
doesn't look difficult to add something like
static;optimized;libsqlite3.a;dynamic;optimized;libsqlite3.so.
There's the problem of find_library on Windows confusing the .lib as
the import for a .dll with a static .lib library but IIRC it's
possible to detect that.
If you use the full path then it should work fine. find_library will
always return the full path. So if you do target_link_libraries(foo
${SQLITELIB}) where SQLITELIB = /usr/lib/libswlite3.a then it will work
just fine.
-Bill
___
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] target_link_libraries: prefer static to dynamic
On Sun, Dec 27, 2009 at 10:59 AM, Michael Wild them...@gmail.com wrote: On 26. Dec, 2009, at 17:53 , Pau Garcia i Quiles wrote: Hello, I think this has already been discussed and the answer is negative but still: when I do target_link_libraries to an external library (for instance, my application needs to link to sqlite), is it possible to tell CMake to link to the static version of sqlite instead of the dynamic version? For instance, in Debian the libsqlite3-dev package contains both the static and the dynamic versions of the library and they have the very same name: /usr/lib/libsqlite3.a /usr/lib/libsqlite3.so ( http://packages.debian.org/sid/i386/libsqlite3-dev/filelist ) Is this feature going to be implemented any time soon? I have not looked at the sources for target_link_libraries but at first sight it doesn't look difficult to add something like static;optimized;libsqlite3.a;dynamic;optimized;libsqlite3.so. There's the problem of find_library on Windows confusing the .lib as the import for a .dll with a static .lib library but IIRC it's possible to detect that. Perhaps a variable CMAKE_FIND_STATIC with the possible values FIRST LAST, ONLY and NEVER, similar to CMAKE_FIND_FRAMEWORK, would fit the bill? No, it won't. If my application links to two libraries, I may want to link statically to libA but dynamically to libB. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ 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] target_link_libraries: prefer static to dynamic
On Sun, Dec 27, 2009 at 6:26 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
Pau Garcia i Quiles wrote:
Hello,
I think this has already been discussed and the answer is negative but
still: when I do target_link_libraries to an external library (for
instance, my application needs to link to sqlite), is it possible to
tell CMake to link to the static version of sqlite instead of the
dynamic version?
For instance, in Debian the libsqlite3-dev package contains both the
static and the dynamic versions of the library and they have the very
same name:
/usr/lib/libsqlite3.a
/usr/lib/libsqlite3.so
( http://packages.debian.org/sid/i386/libsqlite3-dev/filelist )
Is this feature going to be implemented any time soon? I have not
looked at the sources for target_link_libraries but at first sight it
doesn't look difficult to add something like
static;optimized;libsqlite3.a;dynamic;optimized;libsqlite3.so.
There's the problem of find_library on Windows confusing the .lib as
the import for a .dll with a static .lib library but IIRC it's
possible to detect that.
If you use the full path then it should work fine. find_library will always
return the full path. So if you do target_link_libraries(foo ${SQLITELIB})
where SQLITELIB = /usr/lib/libswlite3.a then it will work just fine.
That will not work in the case I was describing, where you have both
the shared and the static versions of the library installed. Futher,
it would be even worse if both the static and the shared versions of
the library are installed but in different paths, because you would
depend on what path is searched first.
As I said if you install libsqlite3-dev on a Debian-based distro, it
will install both /usr/lib/libsqlite3.a and /usr/lib/libsqlite3.so.
How can I be sure find_library will find the static version before the
dynamic one. What happens if the path to the static library is
searched after the path to the shared library?
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
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] target_link_libraries: prefer static to dynamic
On 27. Dec, 2009, at 20:41 , Pau Garcia i Quiles wrote: On Sun, Dec 27, 2009 at 10:59 AM, Michael Wild them...@gmail.com wrote: On 26. Dec, 2009, at 17:53 , Pau Garcia i Quiles wrote: Hello, I think this has already been discussed and the answer is negative but still: when I do target_link_libraries to an external library (for instance, my application needs to link to sqlite), is it possible to tell CMake to link to the static version of sqlite instead of the dynamic version? For instance, in Debian the libsqlite3-dev package contains both the static and the dynamic versions of the library and they have the very same name: /usr/lib/libsqlite3.a /usr/lib/libsqlite3.so ( http://packages.debian.org/sid/i386/libsqlite3-dev/filelist ) Is this feature going to be implemented any time soon? I have not looked at the sources for target_link_libraries but at first sight it doesn't look difficult to add something like static;optimized;libsqlite3.a;dynamic;optimized;libsqlite3.so. There's the problem of find_library on Windows confusing the .lib as the import for a .dll with a static .lib library but IIRC it's possible to detect that. Perhaps a variable CMAKE_FIND_STATIC with the possible values FIRST LAST, ONLY and NEVER, similar to CMAKE_FIND_FRAMEWORK, would fit the bill? No, it won't. If my application links to two libraries, I may want to link statically to libA but dynamically to libB. But then, on Debian a static version of sqlite3 is available, but not on Mac OS X (that is, without compiling it yourself). What should be the behavior there? Perhaps this could be expanded to optional options FIND_STATIC of find_library and find_package? Besides, the variable IS enough: set(CMAKE_FIND_STATIC FIRST) find_library(SQLITE_LIBRARY sqlite3) set(CMAKE_FIND_STATIC LAST) find_library(OTHER_LIBRARY other) Michael ___ 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] target_link_libraries: prefer static to dynamic
On Sun, Dec 27, 2009 at 10:16 PM, Michael Wild them...@gmail.com wrote: On 27. Dec, 2009, at 20:41 , Pau Garcia i Quiles wrote: On Sun, Dec 27, 2009 at 10:59 AM, Michael Wild them...@gmail.com wrote: On 26. Dec, 2009, at 17:53 , Pau Garcia i Quiles wrote: Hello, I think this has already been discussed and the answer is negative but still: when I do target_link_libraries to an external library (for instance, my application needs to link to sqlite), is it possible to tell CMake to link to the static version of sqlite instead of the dynamic version? For instance, in Debian the libsqlite3-dev package contains both the static and the dynamic versions of the library and they have the very same name: /usr/lib/libsqlite3.a /usr/lib/libsqlite3.so ( http://packages.debian.org/sid/i386/libsqlite3-dev/filelist ) Is this feature going to be implemented any time soon? I have not looked at the sources for target_link_libraries but at first sight it doesn't look difficult to add something like static;optimized;libsqlite3.a;dynamic;optimized;libsqlite3.so. There's the problem of find_library on Windows confusing the .lib as the import for a .dll with a static .lib library but IIRC it's possible to detect that. Perhaps a variable CMAKE_FIND_STATIC with the possible values FIRST LAST, ONLY and NEVER, similar to CMAKE_FIND_FRAMEWORK, would fit the bill? No, it won't. If my application links to two libraries, I may want to link statically to libA but dynamically to libB. But then, on Debian a static version of sqlite3 is available, but not on Mac OS X (that is, without compiling it yourself). What should be the behavior there? Perhaps this could be expanded to optional options FIND_STATIC of find_library and find_package? Besides, the variable IS enough: set(CMAKE_FIND_STATIC FIRST) find_library(SQLITE_LIBRARY sqlite3) set(CMAKE_FIND_STATIC LAST) find_library(OTHER_LIBRARY other) Instead of having CMAKE_FIND_STATIC, CMAKE_FIND_FRAMEWORK, CMAKE_FIND_APPBUNDLE, etc, those could be replaced with something like this in find_library: find_library( VAR name | NAMES name1 [name2 ...] [...] VARIANT variant1 [variant2 ...] ) Where variant1, variant2, etc would be shared static framework bundle by default. That'd mean find_libraries searches for shared, static, framework and bundle in that order. With my proposal for find_library, and the one I made in the first e-mail of this thread, if I do: find_library( SQLITE3_LIBRARY_RELEASE sqlite3 VARIANT static shared ) I'd have: SQLITE3_LIBRARY_RELEASE=static;release;/usr/lib/libsqlite3.a But if I do: find_library( SQLITE3_LIBRARY_RELEASE sqlite3 VARIANT shared static ) I'd have: SQLITE3_LIBRARY_RELEASE=share;release;/usr/lib/libsqlite3.so I. e. I'm expressing preference: in the first case I'm saying I'd like to find a static version of sqlite3 but if it's not available, give me the shared version. I could also look for the static version only: find_library( SQLITE3_LIBRARY_RELEASE sqlite3 VARIANT static ) or the shared one: find_library( SQLITE3_LIBRARY_RELEASE sqlite3 VARIANT shared ) Meaning: in the first case I want to find a static version of sqlite3 and fail if it's not available. Neither of those should not be the default, though. So for instance if I do: find_library( SQLITE3_LIBRARY_RELEASE sqlite3 ) That'd would be equivalent to: find_library( SQLITE3_LIBRARY_RELEASE sqlite3 VARIANT shared static framework bundle ) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ 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] target_link_libraries: prefer static to dynamic
Pau Garcia i Quiles wrote:
On Sun, Dec 27, 2009 at 6:26 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
Pau Garcia i Quiles wrote:
Hello,
I think this has already been discussed and the answer is negative but
still: when I do target_link_libraries to an external library (for
instance, my application needs to link to sqlite), is it possible to
tell CMake to link to the static version of sqlite instead of the
dynamic version?
For instance, in Debian the libsqlite3-dev package contains both the
static and the dynamic versions of the library and they have the very
same name:
/usr/lib/libsqlite3.a
/usr/lib/libsqlite3.so
( http://packages.debian.org/sid/i386/libsqlite3-dev/filelist )
Is this feature going to be implemented any time soon? I have not
looked at the sources for target_link_libraries but at first sight it
doesn't look difficult to add something like
static;optimized;libsqlite3.a;dynamic;optimized;libsqlite3.so.
There's the problem of find_library on Windows confusing the .lib as
the import for a .dll with a static .lib library but IIRC it's
possible to detect that.
If you use the full path then it should work fine. find_library will always
return the full path. So if you do target_link_libraries(foo ${SQLITELIB})
where SQLITELIB = /usr/lib/libswlite3.a then it will work just fine.
That will not work in the case I was describing, where you have both
the shared and the static versions of the library installed. Futher,
it would be even worse if both the static and the shared versions of
the library are installed but in different paths, because you would
depend on what path is searched first.
As I said if you install libsqlite3-dev on a Debian-based distro, it
will install both /usr/lib/libsqlite3.a and /usr/lib/libsqlite3.so.
How can I be sure find_library will find the static version before the
dynamic one. What happens if the path to the static library is
searched after the path to the shared library?
What version of CMake are you using? This should work... As of 2.6.2
(I think...) CMake uses full paths to libraries, see policy CMP0003:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#policy:CMP0003. It
does not matter if there are two libraries in the same directory. There
is no way to force find_library to find the static one. However, if you
tell CMake to link to a full path to /usr/lib/libsqlite3.a, it should
link to /usr/lib/libsqlite3.a even if /usr/lib/libsqlite3.so exists.
-Bill
___
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] target_link_libraries: prefer static to dynamic
Hello, I think this has already been discussed and the answer is negative but still: when I do target_link_libraries to an external library (for instance, my application needs to link to sqlite), is it possible to tell CMake to link to the static version of sqlite instead of the dynamic version? For instance, in Debian the libsqlite3-dev package contains both the static and the dynamic versions of the library and they have the very same name: /usr/lib/libsqlite3.a /usr/lib/libsqlite3.so ( http://packages.debian.org/sid/i386/libsqlite3-dev/filelist ) Is this feature going to be implemented any time soon? I have not looked at the sources for target_link_libraries but at first sight it doesn't look difficult to add something like static;optimized;libsqlite3.a;dynamic;optimized;libsqlite3.so. There's the problem of find_library on Windows confusing the .lib as the import for a .dll with a static .lib library but IIRC it's possible to detect that. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ 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
