[CMake] libraryname decoration

[Michael Wild]

On 30. Jul, 2010, at 7:53 , Verweij, Arjen wrote:

> Olaf,
> 
>>>> Why?
>>>> I'm still waiting for someone to post a reason of why a decorated
>>>> name is a problem for them.
>>>> Also waiting on an answer to the code duplication issue.
> 
> Perhaps you should write a proposal that takes care of details, like how you would like to see this decorated. Then write a patch or create a cmake module that takes care of this. I don't see code duplication.
> 
> Arjen

First of all: There is almost NO duplication, since almost every project that does decoration uses different conventions. That's like saying that there is an enormous amount of code duplication because almost every CMake-based project calls PROJECT, ADD_LIBRARY and ADD_EXECUTABLE.

Second: It is impossible for CMake do come up with a good decoration scheme that covers all possible variations. What criteria should enter the decoration? CMake currently chooses only to offer automatic decoration for debug builds, which is IMHO a valid choice. Everything else becomes guesswork. Here a list of possible criteria that sprang to mind, some of which CMake cannot possibly determine:

* build-type (debug, release, release with debug info, etc.)
* 32/64-bit
* compiler suite (e.g. VS{6,7,8,9,10}, Borland, gcc-4.{0..5}, ...)
* SDK (e.g. on Mac) or runtime library on Windows
* single/multi-threaded
* integer size (e.g. for array indices, see Intel MKL)
* license differences (e.g. containing non-free code or DFSG-clean)
* capabilities, such as using ncurses, GNU readline or BSD editline (VERY different),
  using cryptographic software or not (e.g. openssl/gnutls)

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


Michael