John Culleton wrote: > The instructions for cmake describe a more complex and for me at least > confusing process than the traditional process. I recognize that the > developers see virtues in cmake. But perhaps after development is > completed the install process could be boiled down to the usual > method for us busy folks that keep many Open Source products on our > systems.
Unfortunately it can't be. The two big virtues of Autotools are: - They're familiar to users - The final build scripts for released versions are just shell scripts. They run without needing extra programs to be installed and work on most systems with a shell, make, and some other core unix utilities. That's about it. Alternative build systems all provide many other advantages, like: - Portability to Windows and to native Mac OS X IDEs - much saner behaviour - fewer weird corner cases and strange quirks - more comprehensible to mortals - Documented ... but generally require the installation of a build tool on the system. This is increasingly viewed as a worthwhile trade-off. Remember, you can save yourself a bunch of hassle by using packages anyway. > If every product develops its own unique installation > software then life becomes unnecessarily complex. Which is why, instead, they adopt build systems like CMake. Autotools forces developers to build their own unique installation software. As a user, you do not see this, but the developers sure do, and waste many days or weeks on it. You as a user do see the bugs that result from it. Autotools is especially bad for Qt based software and other software that needs additional build steps. Time wasted on the build system is time not spent on more productive coding like fixing bugs and writing enhancements to the software, so a build system that's better for the developers actually benefits you rather significantly. Also, remember that the team aren't paid for this. They're doing it out of personal interest in their own time. I hope you wouldn't generally ask someone who's doing something for you for free to make it much harder for themselves in order to slightly benefit your convenience - and, when you think about it, that's what you're doing. That doesn't mean that comments on the build system aren't valuable, of course, it just means that "easier for the developers" is indeed a very good reason for a build system change. > I have seen other > products (Inkscape as I recall) follow other paths looking for the > ideal installation system. But for the end user the ideal method is > something that works and is reasonably simple and universal. Increasingly, that's CMake. It's far from perfect (in fact, in some ways it's downright horrible) but it works well and it's infinitely saner than autotools. You'll find that more and more projects (including KDE 4) are using it. > Other Open Source products (e.g Gimp) compile and install nicely with > ./configure > make > make install > and have for many years. And Scribus used to. I know. I was one of the people who wasted weeks fiddling with the autotools scripts to track down and fix weird bugs and quirks so that it would work that way. I suggest that you try it, and then tell me why Scribus should use autotools. I promise you'll change your mind once you try to work with it. Autotools is actually pretty horrible for some end users too. If you're building from cvs/svn you'll find that you have to If there are features in the old autotools build system that you think are missing in Scribus's new cmake build infrastructure, please explain what you think is missing and how it should be improved. I'm sure the feedback would be appreciated. -- Craig Ringer
