[Cmake] MSDev multiple build types

Wed Aug 25 11:39:34 EDT 2004

We currently link in several third party libraries - some of them written
in-house. My main headaches are ACE/TAO, STLport and Xerces-C. They each
have different build setups.

- ACE is OK. Everything is in a single lib dir and names end with d for
debug, s for static and sd for static debug libs. No problem.
- Xerces-C is less nice. The libraries are in a lib dir on unix, but on
Windows in Build/Win32/VC6 (debug and release have different names and are
in Debug or Release dir). I have added the Build/Win32/VC6 dir to the link
directories and exported the libraries as "Debug/xerces-c_2D" and
"Release/xerces-c_d". That seems to do the trick.
- STL again seems simple. One dir, different library names BUT ... in debug
mode an extra define is needed. That was a bit tricky, because setting that
in a general header is not possible. The general idea is that the programmer
just #includes <list> and uses the STLport version. We had to force each
programmer to add an include in each header before any other includes.
That's were ADD_DEFINITIONS([debug|optimized] define) would have been a
serious time-saver.

[Note: currently I created a PROJECT without a target for each 3rd party
library. Just to get hold of some CMake files to include that contain info
about required defines, include paths, library paths and library names. So
using the XML library is as easy as adding
"INCLUDE(${XML_SOURCE_DIR}/adm/ExportConfig.cmake)" to your CMakeLists.txt.
*]

We also created CUSTOM_COMMAND entries to compile the IDL files, but we
wanted to use different command-line parameters in debug mode. But that's
not possible because the ADD_CUSTOM_COMMAND lacks the debug|optimized
option. Using a custom header with "#ifdef _DEBUG" and telling the idl
compiler to include that header in each file did some of the work, but
unfortunately some things are simply not possible like that.

We use the INSTALL_xxx commands for preparing the packaging of the software,
but for the 3rd party software we include, we need to copy different files
depending on debug/release modes. Unfortunately this cannot be done. We
found some dirty hacking: we copy all files - debug and release - to the
packaging dir and write a file that lists all libraries that are not needed
in either compilation mode. At run-time a small program will state what mode
it was compiled with. The packaging program runs the test exe and throws
away the unneeded libraries before packaging. It works, but ... a
debug|optimized option would have been nicer and easier to maintain.

Having said all this, the problem is simply that MSDev has these multiple
build type project files. If we were able to force the creation of a project
file with only one build configuration to select, all of this would never
have been a problem. It would simply be a matter of IF-THEN-ELSE flow and
having the developer decide first which build type he/she wants. Just like
we do on Unix.

As I reported earlier, that is not possible. At least not for Visual Studio
6. Setting CMAKE_CONFIGURATION_TYPES myself in CMakeLists.txt does not work.
I noticed that the value is set in a template file and it does not get used
anyway for VS6. The VS6 generator simply performs a line-by-line search and
replace without knowing the structure of the file.

The VS7 generator seems to have code that does indeed create only the
configurations set in the CMAKE_CONFIGURATION_TYPES. Is that correct? There
are plans to move to VS2003 in the near future, so it would be nice to know
in advance if it is possible to restrict a project to a single configuration
with VS2003.

Best regards,
Kris

*: I even tried
MACRO(USE_PROJECT OtherProject)
  INCLUDE(${${OtherProject}_SOURCE_DIR}/adm/ExportConfig.cmake)
END_MACRO(USE_PROJECT)
but I soon had to discover that variables are not resolved recursively ...

> -----Original Message-----
> From: William A. Hoffman [mailto:billlist at nycap.rr.com]
> Sent: Wednesday, August 25, 2004 03:31
> To: Dekeyser, Kris; CMake (E-mail)
> Subject: RE: [Cmake] MSDev multiple build types
>
>
> I suppose it should be more consistent.   LINK_DIRECTORIES did
> not seem to be a problem, because the whole point of having different
> libraries for debug and release was that they usually have
> different names
> but are in the same directory.   If the project is entirely built with
> CMake then CMake will pick the right directory.   Can you
> describe the situation
> you have?   There may be a way to do it without so much change.
>
> -Bill
>
>
> At 07:26 AM 8/24/2004, Dekeyser, Kris wrote:
> >OK, thanks. I got that working.
> >
> >One thing is disturbing me, however. The debug/optimized
> option is AFAIK
> >only available for defining link libraries.
> >
> >Why is it not available to INCLUDE_DIRECTORIES, LINK_DIRECTORIES,
> >ADD_(CUSTOM_COMMAND/DEFINITIONS/EXECUTABLE/LIBRARY/...),
> >INSTALL_(TARGETS/FILES/PROGRAMS) etc.? We can do some hacking with
> >CONFIGURE_FILE, but not everything is possible and adding
> the option support
> >to most of these commands would at least simplify things.
> >
> >- Kris
> >
> >> -----Original Message-----
> >> From: William A. Hoffman [mailto:billlist at nycap.rr.com]
> >> Sent: Monday, August 23, 2004 15:17
> >> To: Dekeyser, Kris; CMake (E-mail)
> >> Subject: Re: [Cmake] MSDev multiple build types
> >>
> >>
> >> You can use the debug or optimized option in these commands:
> >>
> >> LINK_LIBRARIES(library1 <debug | optimized> library2 ...)
> >>
> >> TARGET_LINK_LIBRARIES: Link a target to given libraries.
> >>
> >> TARGET_LINK_LIBRARIES(target library1
> >>                         <debug | optimized> library2
> >>                         ...)
> >>
> >> Specify a list of libraries to be linked into the specified
> >> target. The debug and optimized strings may be used to
> >> indicate that the next library listed is to be used only for
> >> that specific type of build .
> >> http://www.cmake.org/HTML/Documentation.html
> >>
> >> -Bill
> >>
> >>
> >> At 08:51 AM 8/23/2004, Dekeyser, Kris wrote:
> >> >Our project uses some 3rd party libraries that have
> >> different paths and
> >> >names depending on the build type. (e.g. Xerces-C)
> >> >
> >> >MSDev has multi-config project files but CMake unfortunately
> >> can not know in
> >> >advance which build type will be choosen. This makes it
> >> difficult (if not
> >> >impossible) to write a TARGET_LINK_LIBRARIES statement for
> >> that library.
> >> >
> >> >I therefore wanted to force the MSDev user to choose in
> >> advance which build
> >> >type will be used. I wrote the following code in my root
> >> CMakeLists.txt:
> >> >
> >> >OPTION(DEBUG_BUILD "Build for debug?" TRUE)
> >> >IF(DEBUG_BUILD)
> >> >  SET(DebugBuild TRUE)
> >> >  SET(CMAKE_BUILD_TYPE Debug)
> >> >ELSE(DEBUG_BUILD)
> >> >  SET(DebugBuild FALSE)
> >> >  SET(CMAKE_BUILD_TYPE Release)
> >> >ENDIF(DEBUG_BUILD)
> >> >
> >> >That's working fine, but still the developer can select
> >> another build type
> >> >in the MSDev environment and that will point the library
> to the wrong
> >> >libraries. So I added the following:
> >> >
> >> ># MsDev's multiple configurations screw up things with
> >> libraries that have
> >> >different name and/or paths depending on the build configuration
> >> >SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_BUILD_TYPE})
> >> >
> >> >Hoping this would disable the generation of the not-relevant
> >> build types. To
> >> >my disappointment that did not change anything.
> >> >
> >> >"Mastering CMake" chapter 3.5 says: "[...] The variable
> >> >CMAKE_CONFIGURATION_TYPES is used to tell CMake which
> >> configurations to put
> >> >in the workspace.[...]". Am I misinterpreting this or is
> >> this a bug in
> >> >CMake?
> >> >
> >> >Best regards, Kris.
> >> >+-+-+- Email Confidentiality Footer +-+-+-
> >> >Privileged/Confidential Information may be contained in this
> >> message. If you
> >> >are not the addressee indicated in this message (or
> >> responsible for delivery
> >> >of the message to such person), you may not print,
> retain, copy nor
> >> >disseminate this message or any part of it to anyone and you
> >> should notify
> >> >the sender by reply email and destroy this message.
> >> Neglecting this clause
> >> >could be a breach of confidence. Please advise immediately
> >> if you or your
> >> >employer does not consent to Internet email for messages of
> >> this kind.
> >> >Opinions, conclusions and other information in this message
> >> that are not
> >> >related to the official business of my firm shall be
> >> understood as neither
> >> >given nor endorsed by it.
> >> >
> >> >_______________________________________________
> >> >Cmake mailing list
> >> >Cmake at www.cmake.org
> >> >http://www.cmake.org/mailman/listinfo/cmake
> >>
> >+-+-+- Email Confidentiality Footer +-+-+-
> >Privileged/Confidential Information may be contained in this
> message. If you
> >are not the addressee indicated in this message (or
> responsible for delivery
> >of the message to such person), you may not print, retain, copy nor
> >disseminate this message or any part of it to anyone and you
> should notify
> >the sender by reply email and destroy this message.
> Neglecting this clause
> >could be a breach of confidence. Please advise immediately
> if you or your
> >employer does not consent to Internet email for messages of
> this kind.
> >Opinions, conclusions and other information in this message
> that are not
> >related to the official business of my firm shall be
> understood as neither
> >given nor endorsed by it.
> 
+-+-+- Email Confidentiality Footer +-+-+- 
Privileged/Confidential Information may be contained in this message. If you
are not the addressee indicated in this message (or responsible for delivery
of the message to such person), you may not print, retain, copy nor
disseminate this message or any part of it to anyone and you should notify
the sender by reply email and destroy this message. Neglecting this clause
could be a breach of confidence. Please advise immediately if you or your
employer does not consent to Internet email for messages of this kind.
Opinions, conclusions and other information in this message that are not
related to the official business of my firm shall be understood as neither
given nor endorsed by it.