<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 7/30/10 6:16 AM, Olaf van der Spek wrote:
<blockquote
cite="mid:AANLkTikpN1_MPxbWjmAyoe-bBBayP4-CBefdUzt92UFx@mail.gmail.com"
type="cite">
<pre wrap="">On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild <a class="moz-txt-link-rfc2396E" href="mailto:themiwi@gmail.com"><themiwi@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">First of all: There is almost NO duplication, since almost every project that does decoration uses different conventions.
</pre>
</blockquote>
<pre wrap="">
Duplication does not mean that the code is 100% equal.
</pre>
<blockquote type="cite">
<pre wrap="">Second: It is impossible for CMake do come up with a good decoration scheme that covers all possible variations.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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)
</pre>
</blockquote>
<pre wrap="">
Isn't this defined by ABI, just like 32/64 bit?
</pre>
<blockquote type="cite">
<pre wrap="">* 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)
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">
MSVC supports auto linking and Boost shows that using it is even
easier then normal linking.
Olaf</pre>
</blockquote>
<br>
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.<br>
<br>
(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
<a class="moz-txt-link-freetext" href="http://github.com/rpavlik/physical-modeling-utilities">http://github.com/rpavlik/physical-modeling-utilities</a> , for:<br>
<ul>
<li>CreateLaunchers.cmake</li>
<li>CreateDashboardScripts.cmake<br>
</li>
<li>CppcheckTargets.cmake</li>
<li>DoxygenTargets.cmake</li>
<li>SetDefaultBuildType.cmake</li>
<li>EnableExtraCompilerWarnings.cmake</li>
</ul>
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...)<br>
<br>
<pre class="moz-signature" cols="72">--
Ryan Pavlik
Human-Computer Interaction Graduate Student
Virtual Reality Applications Center
Iowa State University
<a class="moz-txt-link-abbreviated" href="mailto:rpavlik@iastate.edu">rpavlik@iastate.edu</a>
<a class="moz-txt-link-freetext" href="http://academic.cleardefinition.com/">http://academic.cleardefinition.com/</a></pre>
</body>
</html>