On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
> On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild <them...@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
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
