[CMake] vcproj2cmake.rb script: announcing new version / hosting questions

Andreas Mohr andi at lisas.de
Wed Jun 16 11:17:49 EDT 2010


Hi,

On Mon, Jun 14, 2010 at 05:00:47PM +0200, Andreas Mohr wrote:
> On Mon, Jun 14, 2010 at 09:54:58AM -0400, Bill Hoffman wrote:
> > To be compatible with CMake, I would say a BSD license would be the  
> > best.  gitorious might be a good starting place.  We tried the converter  
> > here, and it created some odd CMAKE_BUILD_TYPE stuff in the CMake files,  
> > that looked like it would not work with the IDE generators.  
> > CMAKE_BUILD_TYPE is NOT used for IDE project files.
> 
> Ah, right.
> That would perhaps need a solution like the (in)famous
> if(NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE)
> which I've been using at several other places but didn't think of
> correcting when working on this area of the original script.
> (to be fair, I haven't attempted a full-circle conversion to .vcproj on
> Windows yet)
> 
> Thinking more about it, I'm not quite sure how to reach 100%
> preservation of original .vcproj content this way (when doing a
> full-circle conversion, that is).
> After all in an original .vcproj file there are full configurations for
> Debug, Release etc. (which the user then selects in the IDE).
> Thus the converted CMakeLists.txt would _somehow_ have to contain the
> same entire content, like it now does with our - quite obviously insufficient -
> CMAKE_BUILD_TYPE branching.

I've spent some time analyzing this, and indeed there of course is a clean way
to isolate this from single-configuration generators' CMAKE_BUILD_TYPE stuff,
e.g. by defining per-configuration settings such as
set_property(TARGET ... COMPILE_DEFINITIONS_MINSIZEREL ...)

**HOWEVER**, well, in fact it's all falling apart after all:

"[CMake] Add configuration support to include_directories()": http://www.mail-archive.com/cmake@cmake.org/msg18270.html

is the #1 reason that a full round-trip .vcproj --> CMakeLists.txt --> .vcproj
will _NOT_ retain all project content satisfactorily
(i.e. we will have to make the hard choice of hard-coding _either_ the Release
_or_ the Debug .vcproj Configuration's AdditionalIncludeDirectories setting
in the resulting converted CMakeLists.txt), since there isn't a
per-configuration include_directories() setup yet
(at least according to that thread's discussion).

Houston...

Hmm, create bug report?

Andreas Mohr


More information about the CMake mailing list