[CMake] Link directories order

[Renaud Detry]

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.