[CMake] libraryname decoration

[Olaf van der Spek]

On Fri, Jul 30, 2010 at 2:15 PM, Ryan Pavlik <rpavlik at iastate.edu> wrote:
>>> The issue conceptually for me here, is that the code shouldn't/doesn't
>>> necessarily know what exact library name to link against - think
>>> different
>>> versions of libraries, different platforms...
>>
>> Could you give a concrete example? As, again with Boost, I've never
>> seen an issue like this.
>
> see starting at line 272
> http://github.com/rpavlik/vrpn/blob/master/vrpn_Configure.h

I see sometimes you're using a release lib in a debug build.
If that's required, not using auto linking seems like a good option.

>>> What ends up happening in
>>> projects that rely on those kinds of constructs, is your config system
>>> ends
>>> up having to configure a file specifying the library names for the
>>> pragmas
>>> to work, which ends up being more hassle than just handling linking
>>> entirely
>>> within the build system.  (Plus, then you get the whole "I know exactly
>>> what
>>> my project links against and uses" benefit.)
>>> I use boost a lot.  I've only used its auto-linking by accident, when it
>>> guesses the wrong decorated name or wrong location for my platform, at
>>> which
>>> point I realize I missed a library in my build system.  It ends up being
>>> a
>>> slightly more convenient "unresolved symbols" error.
>>
>> Interesting. What was the cause of this issue?
>>
>> Olaf
>
> Exactly what I said: when I failed to realize I needed to link a library for
> one of the boost modules I was using.
> (If you use the deprecated link_directories command you might not notice
> this as often, but I've learned that it's the wrong thing to do and that
> full library paths passed to the linker are the most reliable.)

So you disabled auto linking and then failed to link it manually?
How's that a failure of Boost auto linking?

Olaf