[CMake] converting VS projects to CMake

[Brandon Van Every]

On Feb 8, 2008 11:30 AM, Jesper Eskilson <jesper at eskilson.se> wrote:
>
> Brandon Van Every wrote:
> > Someone asked me the other day why CMake doesn't do this.  I thought I
> > gave him a reasonable answer, that it would be painful to do, and that
> > CMake --> native is a much easier problem than native --> CMake.  But
> > I said I would ask here for other people's opinions on it.  I have
> > experience converting a large Autoconf + GMake project to CMake.  At
> > the time I used piles upon piles of regular expressions.  I can think
> > of more sophisticated ways to do the parsing and translation.  But no
> > matter what technology is chosen, it's a lot of work.  I'm sure the
> > same would be true for MSVC, plus MSVC changes its format every few
> > years.  Does MSVC pose any other special difficulties, other than
> > sheer mind-numbingness of translation?
>
> Having written a naive ruby-script which does little more than just
> extract the source files for you, there a number of difficulties. For
> example:
>
> - Handling post/pre-build commands.
> - Handling file-specific options/settings.
>
> Getting to 95% is probably doable with a lot of (mind-numbing) work,
> getting to 100% is probably impossible. There is always another
> pathological case one wouldn't be able to handle.

Recently I tried to tame an Autoconf + GMake build that had a 400MB
monster of a source tree.  I got close.  I was able to conquer nearly
all syntactic problems for that particular source pool, but I ran out
of time to deal with the semantics.  For instance, there was a lot of
tweaky stuff done on the CC and CXX variables.  This is contrary to
the CMake model, where the compiler is frozen when you select a
generator.  There were some other semantic issues; Autoconf, GMake,
and CMake have a lot of semantic similarities, but there are some
differences that require extra work to redo.  I'm sure it's similar
with MSVC; in fact I wonder if it's a lot worse with MSVC.

I believe that for large projects, the conversion strategy needs to
assume that it'll be unable to automagically translate everything.  It
would be better to present a report of what's converted and what still
needs to be converted.  This would help greatly in estimating the
manual labor of projects.  I don't think I'd try to estimate a large
conversion project again without such a tool.

I have some interest in developing an open source framework for such a
tool, maybe call it the "BaseParse" project or some such.  I'm
ambivalent about trying to develop fullblown translation tools for
free.  It's exceedingly labor intensive, which means it's exceedingly
expensive, which means I gotta eat and I don't like working for months
and months for free.  But perhaps a common framework that deals with
some really basic capabilities, that all consultants and would-be
CMake initiates could start from, would be of value for spreading
CMake.  It would be very helpful if we could tell the world how easy
or difficult their build conversions are likely to be.


Cheers,
Brandon Van Every