On Tuesday 07 Nov 2006 17:36, Guillaume Laurent wrote: > On Tuesday 07 November 2006 17:30, Chris Cannam wrote: > > On Tuesday 07 Nov 2006 16:13, Guillaume Laurent wrote: > > > How do you think KDE chooses its own ? > > > > Ooh, I don't know -- do you think they test some and pick the one > > that appears to be best, instead of picking up whatever another > > project happens to use? You'd hope so, wouldn't you? > > [...] I know how scons and then cmake ended > up being chosen, and it was not because "somebody else is using it".
That's what I was saying, but perhaps my sarcasm was missed. My point was that if the KDE project can choose a system on its merits for their use, why can't we? The reason I'm being so grumpy about this is mostly due to exasperation with comments like "at one point or another, we'll have to migrate to cmake". We don't _have_ to do anything of the sort, and we never will _have_ to. How are we supposed to make a rational decision if we start out by assuming the result? > Not different, our requirements are a superset of KDE's. Not at all. We don't build any shared libraries, we target one platform, we have no system-level code (requiring root privileges for example) and so on. Our requirements are far simpler in the respects in which KDE's are complex. We don't have to build the tools such as dcopidl; we can happily fail if they're not there. All our optional library dependencies are fairly straightforward ones that can be handled with nice easy HAVE_ flags, with the sole exception of ALSA. > But the transparent handling of uic, moc, and dcopidl are something > I'm not too keen on re-inventing, for instance. Why not? Apart from uic, they're all handled by my reorganise-makefile already in a handful of lines. About the same amount of work again to detect whether the programs themselves exist, and you're done. I can understand why we didn't start out with a simple autoconf/Makefile.in system when we first began, because the KDE situation was rather in flux, none of us had ever used autoconf for real, and we just didn't have much clue. But if some angel had come along and made such a system for us, we'd probably still be using it quite happily. Our problems with autotools (apart from actually using automake and libtool instead of just autoconf) had a lot to do with that big morass of scripts in kde_admin/ that nobody wanted to touch and that KDE ultimately abandoned. Then our switch to scons has hardly been a success -- if it had been, we wouldn't be planning to switch again a year and a half later. Again, I don't see scons itself as the problem, but bksys, a big morass of scripts designed for building KDE and then rejected by KDE and abandoned. Are you sensing a theme here? Chris ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
