Hi Michael, *, On Mon, Feb 16, 2009 at 2:04 PM, Michael Stahl <[email protected]> wrote: > On 16/02/2009 13:28, bjoern michaelsen - Sun Microsystems - Hamburg Germany > wrote: >> Jussi Pakkanen wrote: > >> While dmake might be obscure, it fits these requirements pretty well, and >> more is lost than gained IMHO by moving to CMake. > > here's 2 requirements that dmake does not meet: > - familiar to new developers
How often do you really need to modify makefiles by means other than appending a file to a list or copying from another makefile? And dmake of course comes with a manpage. And do you really think that cmake syntax will be more familiar to new developers? Those that are given as one of the benefits of cmake - IDE users? Doubt so... > - maintenance is Someone Else's Problem, not a drag on OOo resources I disagree. If you hit a problem with the maketool in such a project like OOo, you need to fix it yourself in any case - you cannot wait until upstream provides a fix. This is one of the reasons for including copies of external libraries in OOo, this is one of the reasons for rejecting contributions not covered by the SCA. >> CMake might have something going for it as a replacement for the mess that >> is autotools, however thats not an issue with OOo. > > well, i guess noone would disagree with your assessment of autotools, but > that can be explained by the problem that autotools try to solve: building > stuff on any UGLIX system released in the last 20 years. > all these fancy new build systems with shiny features have given up on this > problem, and instead try to solve the simpler problem of getting stuff to > build on _recent_, widely-used systems. I wouldn't say OOo uses autotools. It uses autoconf to convert a "readable" configure.in to a usable configure that can be executed. Any check that is in configure for "cruft" is there because OOo should still be supported on those systems. So switching to a new system that simply prints: "Get a shiny new box and install a recent version of your distro" is not an option. >> If you would offer a migration path from dmake to plain GNU make and from >> tcsh to bash, that might be quite interesting ... > > certainly GNU make would be an improvement over dmake. I also don't see why gnu make would be an improvement over dmake. > [...] Can you build whole KDE in one go with cmake? I doubt so. I guess you build module <foo>, install module <foo> into your system and then go on with <bar>. <bar>'s cmake does it checks and detects that <anothermodule> is missing, hence you build & install <anothermodule> and reiterate.... If this is the case, I wouldn't take KDE as an example of a huge project that uses cmake that can be used as a role-model for OOo. If it is not the case, then please ignore my ignorance. ciao Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
