[CMake] libraryname decoration

[Ryan Pavlik]

  On 7/30/10 6:16 AM, 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.
>
>> 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

If you want to avoid code duplication, write a cmake module that does it 
then share it with the world.  This doesn't have to be a top-down 
solution: if you think you have the best library decoration system 
wrapped in a tidy, documented module, then there's nothing stopping you 
from publicizing it and encouraging projects (instead of project tools) 
to use it.  De-facto, not de-jure.

(In general, this is my approach to things I'd like CMake to do that it 
doesn't yet, and really, if it doesn't need a core change to be 
possible, it's probably the best place for the code.  Look in any of my 
projects on GitHub, like 
http://github.com/rpavlik/physical-modeling-utilities , for:

    * CreateLaunchers.cmake
    * CreateDashboardScripts.cmake
    * CppcheckTargets.cmake
    * DoxygenTargets.cmake
    * SetDefaultBuildType.cmake
    * EnableExtraCompilerWarnings.cmake

to get an idea of how I solve these things - I solve them once in a 
module, which makes its way into open source code, and hopefully if 
folks want to do similar things they end up finding these modules, 
and/or even improving them...)

-- 
Ryan Pavlik
Human-Computer Interaction Graduate Student
Virtual Reality Applications Center
Iowa State University

rpavlik at iastate.edu
http://academic.cleardefinition.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100730/15ccf507/attachment.htm>