Jussi Pakkanen wrote: > On Tue, Feb 2, 2010 at 5:32 PM, bjoern michaelsen - Sun Microsystems - > Hamburg Germany <[email protected]> wrote: > >>> There is also "Pure CMake". But as I said earlier, it is probably >>> smarter to first go "CMake + Unix" and then transition to pure CMake. >> >> You are severely underestimating the dark magic done in the build >> system (mostly concentrated in a few "ugly" modules"), if you believe >> all current ops can be done in "Pure CMake". There are some pretty >> mystical textprocessing operations done using sed, awk, perl etc. >> throughout the build. > > I want to note out the following so no-one will think that I am a > religious zealot: > > CMake *will* take more work up front than GNU Make (which, as I > understand, already works).
It works for some modules, yes. Amongst others for "sw", so we have more or less covered everything that you can find in "normal" modules. We still have to do a lot of work for all the modules that are "different". Please see my mail about the module build targets investigation. > It may be a lot of work, it may be a sh*tload of work. The advantage of CMake is that we have to code only for one "platform": CMake. With GNUMake we surely have to do more "porting". The advantage of GNU Make is in the troubleshooting. >> Going for "Pure CMake" is going to be a lot of >> work and is spoiled if it cant be completed as there is little worth in >> "mostly pure CMake". To request resources for such a project on the >> prospect that it "will probably work out" is unlikely to work out >> with any of the big supporters of OOo. > > I don't think you can ever get rid of Cygwin completely. At the very > least you need Flex and Bison and the easiest way to install them is > to use Cygwin. Then you might as well install other tools as well. > "Pure CMake" was mostly listed for completeness. I guess it should > have said that transitioning to it can be done as an independent step, > at a later time, and only if it is deemed necessary at the time. And > most importantly: you get CMake's benefits even if you never do it at > all. I tend to agree that - whatever we will do - we probably won't get rid of cygwin. Where we have to get rid of it is the building of the "normal" modules. As an example, if a developer is going to work on "sw", he might want to build sw and all c++ libraries it depends on (well, without the external ones). Being able to do that in Visual Studio would be a tremendeous achievement. But using Visual Studio as a "launcher" for cygwin shells is probably not what we want here. So the build of "normal" C++ libraries should run inside VS completely. Building other modules like extras, helpcontent etc. with Cygwin won't hurt in this scenario. But it might have some negative influence on the performance of a complete build if vcbuild is used as the "launcher" for several cygwin shells that we will need to build the "special" modules. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[email protected]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
