[CMake] libraryname decoration

Michael Jackson mike.jackson at bluequartz.net
Fri Jul 30 08:58:37 EDT 2010


On Fri, Jul 30, 2010 at 7:49 AM, Ryan Pavlik <rpavlik at iastate.edu> wrote:
>  On 7/30/10 6:45 AM, Michael Wild 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?
>>
>>>> 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.
>>
>> See, there you say it yourself. CMake has already the scheme of adding a
>> debug suffix. Not perfect, but it's there and it is working. Stop whining
>> and provide a patch.
>>
>>>> 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?
>>
>> Not necessarily. The MKL offers the choice of using 32 bit integers
>> (maximum compatibility) and 64 bit integers (huge arrays).
>>
>> This is a rather dated/historic document, but it describes the various
>> models.
>> http://www.unix.org/version2/whatsnew/lp64_wp.html
>>
>> The MKL supports both, ILP64 and LP64, see this:
>>
>> http://www.intel.com/software/products/mkl/docs/linux/WebHelp/mkl_ug_structure/support_for_ilp64_programming.htm
>>
>>>> * 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.
>>
>> Please do explain. How would this work? What would the API be? 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...)
>>
>> 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!
>>
>> Michael
>
> And, if you ask any auto*-using developer how they feel about detecting and
> configuring boost, prepare for some impolite words.  Even the cmake module
> for detecting it is complex.
>
> (and auto-linking appears to only work on windows with MSVC, and I'm not
> prepared to let #pragma comment(lib, "mylib.lib") surrounded by ifdefs sneak
> into my source code.)
>
> --
> Ryan Pavlik
> Human-Computer Interaction Graduate Student
> Virtual Reality Applications Center
> Iowa State University
>
> rpavlik at iastate.edu
> http://academic.cleardefinition.com/

And what if someone else is using a different naming decoration for
their project than what is in the auto-link headers? Then you have to
update all those headers to your own naming scheme which amounts to a
fork of that project. Which sucks.

Mike Jackson.


More information about the CMake mailing list