[CMake] libraryname decoration

Olaf van der Spek olafvdspek at gmail.com
Fri Jul 30 07:54:35 EDT 2010


On Fri, Jul 30, 2010 at 1:45 PM, Michael Wild <themiwi at gmail.com> wrote:
>
> On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
>
>> On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild <themiwi at gmail.com> wrote:
>>> First of all: There is almost NO duplication, since almost every project that does decoration uses different conventions.
>>
>> Duplication does not mean that the code is 100% equal.
>
> Let's turn this around for once *evilgrin*: Why?

If the code is 100% equal there's no problem. Problems arise when you
alter one copy but forget to alter other copies. At that point there's
inconsistency.

>> On Windows, at least build type, run-time and platform.
>> But what should and what should not be part of the name doesn't have
>> to be fixed. So that's no problem.
>
> Please do explain. How would this work? What would the API be?

I don't know yet.

> And now it suddenly sounds like CMake isn't supposed to do everything automagically anymore. If that is the case, please RTFM and look into the OUTPUT_NAME target property. It offers exactly what you want!
>
>>
>>> The list goes on and on, and you simply can't expect CMake to make the right choice for you (well, it could, but then you would get names that easily exceed the maximum length for filenames of almost any operating system around and linking against that library without CMake would be utter pain).
>>
>> MSVC supports auto linking and Boost shows that using it is even
>> easier then normal linking.
>
> Why? (See how annoying this is? Normally I expect this kind of argumentation/questioning from 4-5 year olds...)

Because I don't have to specify the libs to link against myself.

> To answer partially why I don't think that the boost-way is a solution for every project, just look at how it's implemented.
> http://svn.boost.org/svn/boost/trunk/boost/config/auto_link.hpp
>
> Really cool... THAT's a lot of code that requires a lot of maintenance!

Why?
Yes, it's a lot of code, but why does that imply it requires a lot of
maintenance?

Olaf


More information about the CMake mailing list