On Jul 22, 2010, at 4:54 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 10:46 PM, Michael Jackson
<mike.jack...@bluequartz.net> wrote:
Ya know , I go back and forth on this. In my own projects I will
give my
libs a _debug suffix because I end up installing both debug and
release into
a local directory and my FindXXX.cmake scripts know to look for
both a debug
and release version of the library, ala, FindQt4.cmake. I like the
way Qt
does this and so went with TrollTech's "standard".
If you don't have all the infrastructure to do that then NOT
having any
default naming is the best way.
What do you mean?
Using the same name for all configs?
Shown by your own example, that doesn't work.
Olaf
So here is what really happens with Visual Studio. When you
invoke CMake you select to build "Shared" libraries and a Win64
application. These are the basics. Visual Studio will create a
subdirectory for "Debug" and "Release" variants for you. So when you
build you get a shared library with debug symbols placed in the Build/
Debug/ directory and the same for Release (Build/Release). Now. since
these are completely separate directories when you execute your
program the correct libraries will be found. Great. This falls apart
if you "install" your project to a location for other projects to get
to. Then one library will over write the other.
In a typical CMake workflow one would create another build
directory and rerun CMake again to generate another Visual Studio
solution that would have say a 32 bit Static build in it. This is what
CMake kind of expects. You can abuse this if you want. Take a look at
the boost-cmake project.
Since I use Qt for my apps and they have a set way of doing
things and since CMake can find those libraries in both Debug and
Release variants then I modeled my own projects so they produce the
same type of naming scheme as Qt. This allows me to install both a
Debug and Release version into a location where other projects can
find them, say C:\Developer\i386\MyProject or C:\Developer
\x64\MyProject.
If you want to go even further and decorate your library names
like boost does then go ahead and write the CMake code (or grab it
from the Boost-cmake project). CMake only needs to do what the other
platforms do which is NOT decorate the library names. VS does not do
this by default. Xcode does not. Eclipse does not. Makefiles do not
(unless you write it to). SO that is why CMake does not do it.
You _can_ very easily do this if you want. The code is out there
in the wild in the form of macros that can be invoked from CMake that
will set all of this up for you. You just have to look for it (or ask
the right person... )
Does that help?
Mike Jackson
_______________________________________________
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
