On 7/30/10 6:16 AM, 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.
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
rpav...@iastate.edu
http://academic.cleardefinition.com/
_______________________________________________
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
