[CMake] libraryname decoration

[Michael Wild]

On 30. Jul, 2010, at 13:54 , Olaf van der Spek wrote:

> 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.

Create a module and share it among your projects, possibly with others. If it's any good it might get included in CMake.

Although, I suspect that what you want either requires wrapping add_library and add_executable in custom functions or heavy modifications to cmTarget::GetFullNameInternal().

> 
>>> 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.

So, how is it no problem then?

> 
>> 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.

Yes, you do. Because most people library authors will just refuse to write and maintain an auto_link.hpp

> 
>> 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?

For every new version of MSVC, Xcode etc. you have to update the file. Usually you will be lagging behind, and your users even more so. And then they will complain. To you.

Michael