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.
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
