On Sat, Feb 14, 2009 at 6:19 PM, Christian Lohmaier <[email protected]> wrote:
>> Compared to dmake, CMake has the following advantages for OOo. >> >> - actively being developed > > OOo's dmake is being fixed as well if there are problems, so no real benefit. Who does this fixing? As far as I know the devs at Sun. Every minute they spend on fixing bugs in dmake is time they could be spending on other parts of OOo. OOo already uses a ton of third party libraries rather than waste time coding every single thing from scratch. The same benefits apply to the build system. > actively being developed = might break old makefiles from one release > to another? No, thanks... CMake developers take backwards compatibility extremely seriously. They have a very large testing suite that they run daily on dozens of different platforms. What sort of regression control does dmake have? >> - used widely and thus known by lots of people > > dmake is very similar to make and that is used and known by even more > people, so no real benefit here either. There are actually not that many people who know Make syntax nowadays. Almost no-one writes makefiles, but rather use GNU autotools. Automake syntax is quite different from Make's (or at least as far as I can recall, I have not used Autotools in quite some time). >> - native support for all major platforms and IDEs > > OOo is huge, you will never be able to use an IDE for OOo development > (IMHO), so I don't see any benefit here either. Interesting. Please post a link to a scalability test that supports this claim. Preferably one done by a reliable third party using the newest version of the IDE in question. It also seems to me that IDEs are already used. The OpenOffice wiki has several pages on how to to various things with Visual Studio (debugging with full stack traces etc). Platform support in this case means that CMake also produces build systems that utilize only Make (on Linux, OSX, Cygwin, MinGW etc) or NMake (with MSVC). So those who don't like or have access to an IDE can stick with the command line. >> - cross-platform autoconf replacement > > How is that relevant for OOo? OOo uses configure, environment > variables and "static" makefiles. Firstly the environment variables just go away. There are no shell setting files to source, nor any need to keep the code that creates said source files. Less code to maintain and simpler. And configure is ... well, there's nothing more I can say that the KDE developers have not already explained. See http://lwn.net/Articles/188693//au BTW why do you have quotes around the word "static"? Are they immutable or aren't they? >> - straightforward syntax, no shell magicks required (but you can use >> them if you want to) > > Please give an example where "shell magic" is needed and how that same > construct would look like in cmake. For example cppu/qa/makefile.mk has many targets that do stuff with shell commands. I have no intention of trying to decipher what they are attempting to do until I have to. >> A recurring theme in OOo conference presentations and similar material >> seems to be that hacking on OOo is hard for newcomers partly because >> it is such a complex beast to build. Making it easier could bring in >> more contributors. > > having different maketool will not help. I see no difference whether > the user types "dmake" or "cmake". So how would a different maketool > make it easier for newcomers? I looked at the Windows build instructions in the Wiki. Before you even get to typing "dmake" you have jump through a ton of hoops, such as typing a ten line configure command. This is normal (though annoying) for Linux devs, but very frustrating for Windows people. In contrast, here's how the same would work with CMake. 0. Install prerequisites (this step is the same for both, except that CMake does not need Perl) 1. Open the project with CMake GUI 2. Select Visual Studio output (or Cygwin or KDevelop, or whatever you want) 3. Click 'configure' 4. If some library was not found, set the paths using the GUI 5. Click 'generate' 6. Open project in VS and click "Build". (or run 'make' or ...) This is not a question of typing "cmake" instead of "dmake". It is about never, every having to type anything anywhere (unless you want to, which is totally cool and fully supported). It is about allowing coders to be fully productive with their chosen tools rather than forcing an 1980s straightjacket upon them. It is about using the same established processes and best practices that other projects do. These are the things that make contributing easier for newcomers. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
