Re: [CMake] static library linking

2008-06-15 Thread Brad King
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

Re: [CMake] static library linking

2008-06-15 Thread Brad King
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. Th

[CMake] Inhouse custom module deployment advice

2008-06-15 Thread Nicholas Yue
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 usa

Re: [CMake] static library linking

2008-06-15 Thread Steven Van Ingelgem
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

Re: [CMake] static library linking

2008-06-15 Thread Steven Van Ingelgem
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 t

Re: [CMake] static library linking

2008-06-15 Thread Steven Van Ingelgem
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),

Re: [CMake] static library linking

2008-06-15 Thread Alan W. Irwin
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 whi

Re: [CMake] static library linking

2008-06-15 Thread Steven Van Ingelgem
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 ide

Re: [CMake] static library linking

2008-06-15 Thread Alan W. Irwin
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

Re: [CMake] static library linking

2008-06-15 Thread Brad King
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

Re: [CMake] build type per target?

2008-06-15 Thread Alexander Neundorf
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 appli

[CMake] build type per target?

2008-06-15 Thread Dave Milter
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 SH

Re: [CMake] static library linking

2008-06-15 Thread Steven Van Ingelgem
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

[CMake] Dependencies handling vs. timestamp

2008-06-15 Thread Wojciech Migda
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 leps

Re: [CMake] static library linking

2008-06-15 Thread Alan W. Irwin
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/l

Re: [CMake] File-dependent rebuild

2008-06-15 Thread Wojciech Migda
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 i

Re: [CMake] static library linking

2008-06-15 Thread Steven Van Ingelgem
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

[CMake] Inconsistent CTest/CMake variable naming

2008-06-15 Thread Maik Beckmann
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