Hi Jussi, *, On Sat, Feb 14, 2009 at 7:35 PM, Jussi Pakkanen <[email protected]> wrote: > 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.
Wrong, but doesn't matter. > Every minute > they spend on fixing bugs in dmake is time they could be spending on > other parts of OOo. And a transition to another make system would not spend man-weeks/month of work that could be spend on fixing bugs elsewhere? Furthermore: You don't need to fix stuff that ain't broken. > 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. Sorry, but I absolutely cannot follow your argumentation here. dmake doesn't need to be developed from scratch. It is mature. But if bugs are identified, they do get fixed. It is not that you change dmake every two weeks or so. >> 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. So what benefit gives the "actively being developed tag"? There is none really. Either the tool is mature and working, there's no need to update/change it, or it is broken here and there and needs lot of iterations to get things right (and probably that will require changes to makefiles). > What sort of regression control does dmake have? Well it has OOo and its different platforms as a test-suite... >>> - 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). Using an IDE's debugging tools or an IDE's editor doesn't count as using and IDE to develop or even build OOo in my eyes. >> 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. Then I'd like to see the cmake equivalent of OOo's configure and the resulting different combinations of build-conditionals. > 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 4.0.4 not found. > BTW why do you have quotes around the word "static"? Are they > immutable or aren't they? They are not generated based on other files, as implied by your use of "autotools/automake/whatever" >>> - 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. Please give a concrete line-number. I don't see where that makefile does much stuff with shell commands. > 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 not related to the actual makefile system, just to ge the build-requirements straight. > 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. Even if cmake does check for required software, how does that make it easier for windows users to install those requirements? > 0. Install prerequisites (this step is the same for both, except that > CMake does not need Perl) dmake doesn't require perl either. It is various tools that are used during the build/development that use perl. Don't compare apples with oranges please. > 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 Aha. And that is easier than running configure and if configure complains add the path to configure? Sorry, I'm still not marginally convinced about any benefit that would give. (that doesn't imply you should stop trying, but in my opinion this is just a big waste of time and ressources that only gives cool colored output but no other benefit)... ciao Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
