On Feb 8, 2008 11:30 AM, Jesper Eskilson <[EMAIL PROTECTED]> 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 _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake