[CMake] Link directories order
Renaud Detry
renaudjdetry at airpost.net
Fri Nov 9 06:40:25 EST 2007
On 08 Nov 2007, at 17:52, Bill Hoffman wrote:
> Renaud Detry wrote:
>>>>> 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.
>>> Ok, create a bug report. It still is not the CMake way of doing
>>> things. CMake should be told the full path to libraries you want
>>> to use. That way it knows exactly what you are trying to do.
>>> Parsing compiler specific flags out of LDFLAGS to add path
>>> information was not what I had in mind when I used LDFLAGS.
>>> Perhaps I should not have used it at all, or used a different
>>> variable. When I added the ability to use LDFLAGS, I think I was
>>> adding support for 64 bit IRIX builds, needed -64 as a linker
>>> flag. Although at this point, I can not remove it because of
>>> backwards compatibility, so I guess I am stuck with parsing it
>>> for -L. But, if you want your stuff to work with a release
>>> cmake, you might want to consider doing something different.
>> Ok, I'm sure I'll find a way. CMake is a great tool anyway, thanks!
>
> Thanks, for the good attitude! :)
>
> You did bring up a use case that I had not anticipated. If you
> could create a bug report, it would be a good idea to at least look
> for -L in the linker flags in my order directory stuff. Someone
> could just as easily added a -L flag via CMAKE_LINKER_FLAGS or some
> other cmake variable that ends up in the link line.
Ok, I'll look into that, next week.
Cheers,
Renaud.
More information about the CMake
mailing list