[CMake] Project being (unnecessarily) relinked

[Mike Jackson]

On Sep 13, 2007, at 2:49 AM, Dizzy wrote:

> On Wednesday 12 September 2007 15:45:52 Bill Hoffman wrote:
>> Jesper Eskilson wrote:
>>> Really you should be using full paths to libraries and not
>>> LINK_DIRECTORIES anyway.
>>>
>>>
>>> Why not? Is that a general advice about LINK_DIRECTORIES?
>>
>> Yes, if cmake knows the full path to the library it can handle it  
>> much
>> better.
>> If you just specify the name of the directory and the library  
>> cmake does
>> not know anything about the library.  But the problem should be the
>> opposite of the one you are having.  It should rebuild less than  
>> it should
>> when link_directories is used.
>
> Sorry to drop in but how portable is this? Right now I too have
> some "convenience libraries" (libraries made with add_library but  
> never
> installed to gather some code and be used from various targets) and  
> to have
> target_link_libraries() "see" them I set first link_directories()  
> to their
> locations. I do this because I worry about the portability of full  
> library
> paths. How do I know what is the full library name on any cmake  
> platform? I
> supose on mingw/gcc it is always libname.a (for a add_library 
> (name ...)) but
> probably with msvc there is another name for it (as add_library()  
> does not
> specify the full name but the "platform independent" name that  
> translates to
> libname.a and so on) and with target_link_libraries() not using  
> full paths
> one also specifies the "platform independent" name of it (just
> target_link_libraries(target name) and not
> target_link_libraries(target /path/to/libname.a)).
>
> What am I missing? :)
>
> Thanks!
>
> -- 
> Mihai RUSU					Email: dizzy at roedu.net
> GPG : http://dizzy.roedu.net/dizzy-gpg.txt	WWW: http://dizzy.roedu.net
> 			"Linux is obsolete" -- AST
>

Thinking out of the box, here is one way I solved this problem. Say  
your first project builds a library Foo. Then install that library in  
what ever location you want to install it. Then set an environment  
variable "FOO_ROOT" that points to the top level install directory.  
So typically you would install things in /usr/local/ (on a unix  
machine), then "make install" should put libFoo.a in the "lib"  
directory in /usr/local. That was all part 1.

Next, in your 2nd project that depends on the Foo you need to add  
some things into your cmakelists.txt file:
#---------------------------------
#  This will set FOO_LIB_DIR to the environment variable set by the user
IF ( NOT FOO_LIB_DIR )
    SET(FOO_LIB_DIR "$ENV{FOO_ROOT}/lib" )
ENDIF ( NOT FOO_LIB_DIR )
# --- If the user does NOT have the environment variable set then  
default to the current build directory
IF ( NOT FOO_LIB_DIR )
   SET(FOO_LIB_DIR  ${PROJECT_BINARY_DIR}/Bin )
ENDIF ( NOT FOO_LIB_DIR )

# ------------ Find Foo Library  ----------------------
# FOO_LIB will show up in ccmake/cmakesetup with the platform  
specific path if the following is found.
# Otherwise the user can manually find the library in ccmake/ 
cmakesetup and the FOO_LIB variable will
# be set appropriately. You can also specify other directories to  
look in. Cmake has some default locations
# that it will look in when trying to find the library.
FIND_LIBRARY(FOO_LIB Foo
	${FOO_LIB_DIR}
)

#--- Lastly Compile and link your executable ---------------------
ADD_EXECUTABLE( MyExecutable  ${MySrcs} )
TARGET_LINK_LIBRARIES( MyExecutable ${FOO_LIB} )

This type of setup will solve the "use absolute paths" where possible  
that Bill Suggested. Not sure if it will solve the linking problem  
though..

Hope that helps explain some things.
-- 
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services