[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