[CMake] Link directories order

Renaud Detry renaudjdetry at airpost.net
Thu Nov 8 03:53:56 EST 2007


>>> OK, CMake does not know what you are doing here.  It is treating  
>>> LDFLAGS like some linker flag.  The idea was something like -64  
>>> or some other linker specific flag for a platform.
>> Ok.
>>> If you inject directories into the link line, you are sort of out  
>>> of luck.  Why are you doing it this way?
>> What other way could I do it?
>> - There's no official definition of what should be found in LDFLAGS,
>>   but most of the software that use LDFLAGS (in particular autotools)
>>   expect you to put non-standard link directories in there.
> You should be using FIND_LIBRARY to find the things you want to  
> link in, or at least finding the directory with a FIND_FILE, and  
> then using LINK_DIRECTORIES. LDFLAGS is a bad idea because your  
> users will also have to set this to get it to work.

I don't really agree here. Users can decide to install in a standard
directory (e.g. /usr/local is standard for headers and libs in many
linux distros) and it will work right away. Or users can choose to
install in a non-standard directory like $HOME/usr, and it's their
responsibility to keep their CPPFLAGS & LDFLAGS up to date.

The FIND_* primitives are neat when used with a restricted scope
(cf. CMAKE_LIBRARY_PATH), and I'm ok with keeping the env vars
CMAKE_*_PATH up-to-date. However, I need to keep link dirs in LDFLAGS
anyway because that's what other build systems expect. The point is,
IMHO CMake should:

- Either *ignore* LDFLAGS, and optionally get linker flags other than
   -L from an env var like CMAKE_LINK_FLAGS;

- Either use LDFLAGS, but parse it with respect its content.

For this reason, I think I should report this issue as a bug rather
than a feature request.


Renaud.



More information about the CMake mailing list