[CMake] Project being (unnecessarily) relinked

[Dizzy]

On Friday 14 September 2007 16:19:05 Bill Hoffman wrote:
> Dizzy wrote:
> > What you are sugesting solves the problem for installable libraries
> > (which were installed in a previous to "cmake time", the time where
> > FIND_LIBRARY() runs). Problem with "convenience libraries" of a project
> > is that they have not been built already when cmake runs for that project
> > (so FIND_LIBRARY cannot find them). Using full paths to them (by using of
> > CMAKE_BUILD_DIR and such variables) seems unportable (or maybe I miss
> > something).
>
> Full paths by the use of PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR and such
> variables is very portable.   If Cmake is building the library, then you
> only need to use the target
>  name to find it.

The path itself is portable but the library name (which must exist in a full 
library path) isn't.

I mean imagine this project:

proj
proj/CMakeLists.txt:

project(prog)
add_subdirectory(lib)
add_subdirectory(exe)
EOF

proj/lib/CMakeLists.txt:
add_library(a lib.c lib.h)
EOF

proj/exe/CMakeLists.txt:

add_executable(prog main.cpp)
target_link_libraries(prog ${PROJECT_BINARY_DIR}/lib/a)
EOF

This obviously does not work (tries to build an unknown target "a") and to 
make it work I have to write 
target_link_libraries(prog ${PROJECT_BINARY_DIR}/lib/liba.a)

But then if I use "liba.a" as above isn't this unportable? Since with other 
than mingw/gcc compilers the output library name isn't "liba.a" but 
probably "a.lib" and such. In that case the library wouldn't be found right?

Sorry if this has already been answered...

PS: currently I use link_directories(${PROJECT_BINARY_DIR}/lib) and 
target_link_libraries(prog a) which seems to work fine but I raised this 
issue as you sugested to Jesper that he should use full paths with 
target_link_libraries() which adds this limitation :)

-- 
Mihai RUSU					Email: dizzy at roedu.net
GPG : http://dizzy.roedu.net/dizzy-gpg.txt	WWW: http://dizzy.roedu.net
			"Linux is obsolete" -- AST