[CMake] libraryname decoration

[Olaf van der Spek]

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.

> Second: It is impossible for CMake do come up with a good decoration scheme that covers all possible variations.

Why would this optional scheme have to cover every possible variation?
It's like you're saying that because something can't be done
perfectly, nothing should be done at all.

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

Isn't this defined by ABI, just like 32/64 bit?

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

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.

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

Olaf