[CMake] Inconsistent CTest/CMake variable naming
Hello, I wonder if the following name inconsistency is by intention or an oversight. In cmake scripts there are CMAKE_SOURCE_DIR CMAKE_BINARY_DIR and in ctest the counterparts are called CTEST_SOURCE_DIRECTORY CTEST_BINARY_DIRECTORY Why not CTEST_SOURCE_DIR CTEST_BINARY_DIR ?? Thanks, -- Maik ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static library linking
A small example (and verified on a clean SUSE installation): PROJECT(test) cmake_policy(SET CMP0003 NEW) ADD_EXECUTABLE( test main.cpp ) TARGET_LINK_LIBRARIES( test /usr/lib/libpthread.a /usr/lib/librt.a /usr/lib/libc.a ) == this won't set the .a's in the commandline as it should do, but rather link it via -Wl,-Bstatic... And I really need those static links, because no single other library on the system exports the required symbols, not even the shared ones. Greetings 2008/6/15 Steven Van Ingelgem [EMAIL PROTECTED]: Hi, I have a question about CMP0003... When I give the full path to a static library, it's supposed to link against that one... But right now I'm linking against: /usr/lib/libpthread.a (message before the target_link_libraries call) This results however in -Wl,-Bstatic -lpthread... Which doesn't seem like the correct behaviour? What could be the reason for this? Thanks, Steven ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] File-dependent rebuild
I'd like to have cmake rebuild upon detecting changes made to a file being part of the project (simple timestamp difference might suffice). This file is not a compiler input itself, but is used to determine the list of source files upon which the library to build is dependant. The file of interest is a versioned object. OK, I've found a solution, mainly inspired by this thread (http://www.cmake.org/pipermail/cmake/2007-July/015357.html). To explicitly add cmake dependency, which basicaly means calling AddCMakeDependFile, I've used the CONFIGURE_FILE command. In this context it simply copies the file to a designated directory (or files, a total of which in the whole build tree in my case is approx. 140) and ends up adding required entry to the CMAKE_FILE_DEPENDS variable in CMakeFiles/Makefile.cmake. -Wojciech -- Podbij Dziki Zachod!Gra strategiczna online Sprawdz http://link.interia.pl/f1dff ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static library linking
On 2008-06-15 11:47+0200 Steven Van Ingelgem wrote: A small example (and verified on a clean SUSE installation): PROJECT(test) cmake_policy(SET CMP0003 NEW) ADD_EXECUTABLE( test main.cpp ) TARGET_LINK_LIBRARIES( test /usr/lib/libpthread.a /usr/lib/librt.a /usr/lib/libc.a ) == this won't set the .a's in the commandline as it should do, but rather link it via -Wl,-Bstatic... And I really need those static links, because no single other library on the system exports the required symbols, not even the shared ones. Out of curiosity, why doesn't -Wl,-Bstatic -lpthread do exactly what you want? According to the Linux ld man page, -Bstatic means do not link against shared libraries so shouldn't that have the identical result as specifying /usr/lib/libpthread.a? To double-check what is happening with the linking, use ldd -r to list all the shared (but not static) libraries being linked to by test and to show any symbols which are not resolved by the link. You can also use nm to look for unresolved symbols. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Dependencies handling vs. timestamp
Hi, does cmake support handling of a situation when the timestamp of the file upon which trigger for a given action is dependent (compilation, build system regeneration) moves to past? -Wojciech -- Sprawdz, czy jestes lepszy, niz Leo! kliknij http://link.interia.pl/f1e2f ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static library linking
Hi Alan, I don't know why, but if I take the build command from cmake, and I insert the static libraries in there, it works all right. So somehow it's reverting itself to some other version of the static and/or dynamic libraries. The entire point of me reporting this in fact is that in cmake cvs this should have been resolved... Meaning that if I say in my CMakeLists file to link against the static library, it should just keep that link... Not try to be smart and change it ;-). Greetings, Steven 2008/6/15 Alan W. Irwin [EMAIL PROTECTED]: On 2008-06-15 11:47+0200 Steven Van Ingelgem wrote: A small example (and verified on a clean SUSE installation): PROJECT(test) cmake_policy(SET CMP0003 NEW) ADD_EXECUTABLE( test main.cpp ) TARGET_LINK_LIBRARIES( test /usr/lib/libpthread.a /usr/lib/librt.a /usr/lib/libc.a ) == this won't set the .a's in the commandline as it should do, but rather link it via -Wl,-Bstatic... And I really need those static links, because no single other library on the system exports the required symbols, not even the shared ones. Out of curiosity, why doesn't -Wl,-Bstatic -lpthread do exactly what you want? According to the Linux ld man page, -Bstatic means do not link against shared libraries so shouldn't that have the identical result as specifying /usr/lib/libpthread.a? To double-check what is happening with the linking, use ldd -r to list all the shared (but not static) libraries being linked to by test and to show any symbols which are not resolved by the link. You can also use nm to look for unresolved symbols. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] build type per target?
In my project I have plugin for qt designer,
it should be build in release mode, because of in other case qt
designer will not load and use it.
From other hand I need this code as static library,
and use build type the same as my main application uses.
So it looks like
add_library(some_name SHARED
${some_code}
${extra_code}
)
add_library(some_name1 STATIC
${some_code}
)
And I would like to have build type for some_name = Release,
and for some_name1 the same mode as CMAKE_BUILD_TYPE,
is it possible?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] build type per target?
On Sunday 15 June 2008, Dave Milter wrote:
In my project I have plugin for qt designer,
it should be build in release mode, because of in other case qt
designer will not load and use it.
From other hand I need this code as static library,
and use build type the same as my main application uses.
So it looks like
add_library(some_name SHARED
${some_code}
${extra_code}
)
add_library(some_name1 STATIC
${some_code}
)
And I would like to have build type for some_name = Release,
and for some_name1 the same mode as CMAKE_BUILD_TYPE,
is it possible?
I think this is currently not possible.
You could set the COMPILE_FLAGS property for the specific targets.
I'm not quite sure how the CMAKE_CXX_COMPILER_FLAGS and friends are handled,
if they are project-global (I don't think so), ot directory-global (maybe) or
local where they appear (also maybe).
You could set these variables just as you need them and see what happens.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static library linking
Steven Van Ingelgem wrote: I don't know why, but if I take the build command from cmake, and I insert the static libraries in there, it works all right. So somehow it's reverting itself to some other version of the static and/or dynamic libraries. The entire point of me reporting this in fact is that in cmake cvs this should have been resolved... Meaning that if I say in my CMakeLists file to link against the static library, it should just keep that link... Not try to be smart and change it ;-). http://www.cmake.org/Wiki/CMake_2.6_Notes#Linking_to_System_Libraries -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static library linking
On 2008-06-15 19:28+0200 Steven Van Ingelgem wrote: Hi Alan, I don't know why, but if I take the build command from cmake, and I insert the static libraries in there, it works all right. So somehow it's reverting itself to some other version of the static and/or dynamic libraries. You would only link to a dynamic library if there was a bug in ld on your system so that -Bstatic was ignored. That's unlikely, but please exclude that possibility completely by running ldd -r on the executable to get a complete list of shared libraries that are being used (and also the -r option gives you any unresolved symbols for your executable). If you are getting the wrong static library, then that means you have some library search path where something other than /usr/lib is first on that path. I wonder if you have the wrong version of the static library in /usr/local/lib, and that path is first on the library search path for your distro? The entire point of me reporting this in fact is that in cmake cvs this should have been resolved... Meaning that if I say in my CMakeLists file to link against the static library, it should just keep that link... Not try to be smart and change it ;-). You might be right, but I think you have to make your case with more detail. IOW, please do everything you can to identify the actual library being used by the -Wl,-Bstatic -lpthread compiler option on your system. I mentioned ldd -r above to eliminate one (remote) possibility. Also, I assume there is a way to get the linker (ld) to list the actual static libraries it uses, but my linker knowledge doesn't stretch that far. _Thus, I hope some linker expert here will be able to tell you how to do that._ But if nobody else comments, perhaps you can find the alternative static library on your system and infer you are using that (for example, if nm on the alternate static library shows none of the symbols that ldd -r shows are undefined for the executable). Note, I am not a CMake developer, but I do have an interest in linking issues which is why I am curious as to why -Wl,-Bstatic -lpthread is not doing the expected thing on your system. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static library linking
Hi Alan, It doesn't want to link with the -Bstatic... But it links nicely with the static paths... In fact on the system is only 1 libpthread.a ... And that's not what is getting linked against because it returns errors related to symbols which cannot be found in the .so (somehow). I have no idea what's going on, but getting a list of ld which libraries it will link would certainly be helpful. Thanks 2008/6/15 Alan W. Irwin [EMAIL PROTECTED]: On 2008-06-15 19:28+0200 Steven Van Ingelgem wrote: Hi Alan, I don't know why, but if I take the build command from cmake, and I insert the static libraries in there, it works all right. So somehow it's reverting itself to some other version of the static and/or dynamic libraries. You would only link to a dynamic library if there was a bug in ld on your system so that -Bstatic was ignored. That's unlikely, but please exclude that possibility completely by running ldd -r on the executable to get a complete list of shared libraries that are being used (and also the -r option gives you any unresolved symbols for your executable). If you are getting the wrong static library, then that means you have some library search path where something other than /usr/lib is first on that path. I wonder if you have the wrong version of the static library in /usr/local/lib, and that path is first on the library search path for your distro? The entire point of me reporting this in fact is that in cmake cvs this should have been resolved... Meaning that if I say in my CMakeLists file to link against the static library, it should just keep that link... Not try to be smart and change it ;-). You might be right, but I think you have to make your case with more detail. IOW, please do everything you can to identify the actual library being used by the -Wl,-Bstatic -lpthread compiler option on your system. I mentioned ldd -r above to eliminate one (remote) possibility. Also, I assume there is a way to get the linker (ld) to list the actual static libraries it uses, but my linker knowledge doesn't stretch that far. _Thus, I hope some linker expert here will be able to tell you how to do that._ But if nobody else comments, perhaps you can find the alternative static library on your system and infer you are using that (for example, if nm on the alternate static library shows none of the symbols that ldd -r shows are undefined for the executable). Note, I am not a CMake developer, but I do have an interest in linking issues which is why I am curious as to why -Wl,-Bstatic -lpthread is not doing the expected thing on your system. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static library linking
On 2008-06-15 21:58+0200 Steven Van Ingelgem wrote: Hi Alan, It doesn't want to link with the -Bstatic... But it links nicely with the static paths... In fact on the system is only 1 libpthread.a ... And that's not what is getting linked against because it returns errors related to symbols which cannot be found in the .so (somehow). I have no idea what's going on, but getting a list of ld which libraries it will link would certainly be helpful. Hi Steven: Brad's link http://www.cmake.org/Wiki/CMake_2.6_Notes#Linking_to_System_Libraries gives a lot of the relevant background as to why CMake specifies linking the way it does and at the end gives you a way to do exactly what you want (specify the exact static library). My thanks to Brad for drawing my attention to that link. But if you (Steven) are curious enough to further pursue the -l issue which you seem to have discovered (which might be a good idea anyhow since something may be fundamentally wrong with your linker version), please let me know the complete link command (and any associated warning or error messages). To do that use the make VERBOSE=1 option. Please also send the complete results of running ldd -r on the executable that is produced. (If there is a linking error, you can run the linking command again by hand using the --noinhibit-exec option to generate an executable regardless of most errors.) Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static library linking
Hmmm?
I don't seem to be able to make it link correctly?
I do:
set_property(TARGET ${SUB_PROJECT} PROPERTY IMPORTED_LOCATION ${PTHREAD}
${RT} ${LIBC})
But it's still somehow linking wrongly :(...
What would be the correct line for this?
The weird thing is... When I turn it off (the linking), it still tries to
link against pthread, rt libc... I have no idea why? Doesn't it regenerate
the makefiles when you modify the CMakeLists.txt?
Thanks
2008/6/15 Alan W. Irwin [EMAIL PROTECTED]:
On 2008-06-15 21:58+0200 Steven Van Ingelgem wrote:
Hi Alan,
It doesn't want to link with the -Bstatic... But it links nicely with the
static paths...
In fact on the system is only 1 libpthread.a ... And that's not what is
getting linked against because it returns errors related to symbols which
cannot be found in the .so (somehow).
I have no idea what's going on, but getting a list of ld which libraries
it
will link would certainly be helpful.
Hi Steven:
Brad's link
http://www.cmake.org/Wiki/CMake_2.6_Notes#Linking_to_System_Librariesgives
a lot of the relevant background as to why CMake specifies linking the way
it does and at the end gives you a way to do exactly what you want (specify
the exact static library). My thanks to Brad for drawing my attention to
that link.
But if you (Steven) are curious enough to further pursue the -l issue which
you seem to have discovered (which might be a good idea anyhow since
something may be fundamentally wrong with your linker version), please let
me know the complete link command (and any associated warning or error
messages). To do that use the make VERBOSE=1 option. Please also send the
complete results of running ldd -r on the executable that is produced.
(If
there is a linking error, you can run the linking command again by hand
using the --noinhibit-exec option to generate an executable regardless of
most errors.)
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting
software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static library linking
Another issue I just noticed... If you link to an add_library or so, it
will add all the target linked libraries of the original add_library,
which is rather incorrect imho because I don't want to link every library to
a 100M static library, that is only compiled in in 1 shared library...
Is there somehow I can turn this off?
Thanks!
2008/6/15 Steven Van Ingelgem [EMAIL PROTECTED]:
Hmmm?
I don't seem to be able to make it link correctly?
I do:
set_property(TARGET ${SUB_PROJECT} PROPERTY IMPORTED_LOCATION ${PTHREAD}
${RT} ${LIBC})
But it's still somehow linking wrongly :(...
What would be the correct line for this?
The weird thing is... When I turn it off (the linking), it still tries to
link against pthread, rt libc... I have no idea why? Doesn't it regenerate
the makefiles when you modify the CMakeLists.txt?
Thanks
2008/6/15 Alan W. Irwin [EMAIL PROTECTED]:
On 2008-06-15 21:58+0200 Steven Van Ingelgem wrote:
Hi Alan,
It doesn't want to link with the -Bstatic... But it links nicely with the
static paths...
In fact on the system is only 1 libpthread.a ... And that's not what is
getting linked against because it returns errors related to symbols which
cannot be found in the .so (somehow).
I have no idea what's going on, but getting a list of ld which libraries
it
will link would certainly be helpful.
Hi Steven:
Brad's link
http://www.cmake.org/Wiki/CMake_2.6_Notes#Linking_to_System_Librariesgives
a lot of the relevant background as to why CMake specifies linking the way
it does and at the end gives you a way to do exactly what you want
(specify
the exact static library). My thanks to Brad for drawing my attention to
that link.
But if you (Steven) are curious enough to further pursue the -l issue
which
you seem to have discovered (which might be a good idea anyhow since
something may be fundamentally wrong with your linker version), please let
me know the complete link command (and any associated warning or error
messages). To do that use the make VERBOSE=1 option. Please also send the
complete results of running ldd -r on the executable that is produced.
(If
there is a linking error, you can run the linking command again by hand
using the --noinhibit-exec option to generate an executable regardless of
most errors.)
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and
Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting
software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads
of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static library linking
I re-read my post and I gotta say I'm -again- unclear... Let me put this
more detailed:
===
add_library(
somename
shared
a.cpp)
target_link_libraries(somename /somepath/lib100m.a)
add_library(
otherlib
shared
b.cpp)
target_link_libraries(otherlib somename)
===
The first lib will link against lib100m.a.
The second lib however will link against both libsomename.so and the
lib100m.a... The first lib-linking is correct, but the second one is not
as that's not what I want... I want to use the symbols in the lib100m.a
inside the first library, and use those to calculate stuff in there, but
they're of no use whatsoever inside the second shared library... Because
this one only uses symbols exported from the libsomename.so, not from
lib100m.a.
Hopefully that makes my issue more clear ;).
Greetings
2008/6/15 Steven Van Ingelgem [EMAIL PROTECTED]:
Another issue I just noticed... If you link to an add_library or so, it
will add all the target linked libraries of the original add_library,
which is rather incorrect imho because I don't want to link every library to
a 100M static library, that is only compiled in in 1 shared library...
Is there somehow I can turn this off?
Thanks!
2008/6/15 Steven Van Ingelgem [EMAIL PROTECTED]:
Hmmm?
I don't seem to be able to make it link correctly?
I do:
set_property(TARGET ${SUB_PROJECT} PROPERTY IMPORTED_LOCATION ${PTHREAD}
${RT} ${LIBC})
But it's still somehow linking wrongly :(...
What would be the correct line for this?
The weird thing is... When I turn it off (the linking), it still tries to
link against pthread, rt libc... I have no idea why? Doesn't it regenerate
the makefiles when you modify the CMakeLists.txt?
Thanks
2008/6/15 Alan W. Irwin [EMAIL PROTECTED]:
On 2008-06-15 21:58+0200 Steven Van Ingelgem wrote:
Hi Alan,
It doesn't want to link with the -Bstatic... But it links nicely with
the
static paths...
In fact on the system is only 1 libpthread.a ... And that's not what is
getting linked against because it returns errors related to symbols
which
cannot be found in the .so (somehow).
I have no idea what's going on, but getting a list of ld which libraries
it
will link would certainly be helpful.
Hi Steven:
Brad's link
http://www.cmake.org/Wiki/CMake_2.6_Notes#Linking_to_System_Librariesgives
a lot of the relevant background as to why CMake specifies linking the
way
it does and at the end gives you a way to do exactly what you want
(specify
the exact static library). My thanks to Brad for drawing my attention to
that link.
But if you (Steven) are curious enough to further pursue the -l issue
which
you seem to have discovered (which might be a good idea anyhow since
something may be fundamentally wrong with your linker version), please
let
me know the complete link command (and any associated warning or error
messages). To do that use the make VERBOSE=1 option. Please also send
the
complete results of running ldd -r on the executable that is produced.
(If
there is a linking error, you can run the linking command again by hand
using the --noinhibit-exec option to generate an executable regardless of
most errors.)
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and
Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting
software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads
of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Inhouse custom module deployment advice
Hi, I am building up a collection of custom Find***.cmake module which I'd like to roll out internally to multiple platform Linux/Windows/OSX and various variant of each of them. I like to have only one copy of each module file. I know there is the CMAKE_MODULE_PATH but from my current usage of the variable, I have to tell cmake explicitly. This means more work for each new developer or automated build client I deploy. Is there a better or more efficient way to tell cmake (on all platform) where to find additional module files? Regards -- Nicholas Yue BSc (Hons) MACM Graphics - RenderMan, RIB, Visualization, OpenGL, netCDF Custom Dev - C++ porting, OSX, Linux, Windows http://www.proceduralinsight.com/about.html ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static library linking
Steven Van Ingelgem wrote:
I don't seem to be able to make it link correctly?
I do:
set_property(TARGET ${SUB_PROJECT} PROPERTY IMPORTED_LOCATION ${PTHREAD}
${RT} ${LIBC})
But it's still somehow linking wrongly :(...
What would be the correct line for this?
You've mis-read the example. The target property should be set on a
special IMPORTED target. An IMPORTED target is a logical CMake target
that can be linked but is not built. Instead it points at an external
file. By using an imported target you can give CMake alot more information.
Try this:
# add imported target
add_library(imp_pthread STATIC IMPORTED)
# point the imported target at the real file
set_property(TARGET imp_pthread PROPERTY
IMPORTED_LOCATION /usr/lib/libpthread.a)
# import some more libs
add_library(imp_rt STATIC IMPORTED)
set_property(TARGET imp_rt PROPERTY
IMPORTED_LOCATION /usr/lib/librt.a)
add_library(imp_c STATIC IMPORTED)
set_property(TARGET imp_c PROPERTY
IMPORTED_LOCATION /usr/lib/libc.a)
# Now link to the imported targets
target_link_libraries(myexe imp_pthread imp_rt imp_c)
This will produce your desired link line. More info on imported targets
is here:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Importing_Targets
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static library linking
Steven Van Ingelgem wrote: Another issue I just noticed... If you link to an add_library or so, it will add all the target linked libraries of the original add_library, which is rather incorrect imho because I don't want to link every library to a 100M static library, that is only compiled in in 1 shared library... Is there somehow I can turn this off? http://www.cmake.org/HTML/cmake-2.6.html#prop_tgt:LINK_INTERFACE_LIBRARIES add_library(mySharedLib mysharedlib.c) target_link_libraries(mySharedLib myHugeStaticLib) set_property(TARGET mySharedLib PROPERTY LINK_INTERFACE_LIBRARIES ) -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
