On Tuesday 21 August 2007, Daniel Hulme wrote:
Incksape uses autopackage, Sciribus uses Cmake, most other packages still use ./configure followed by make. We are I fear headed for a kind of tower of Babel with install methods on Open source programs.
I don't think we are, for two reasons.
The first is that I remember when almost every project used the same build system, and that build system consisted of editing the Makefiles by hand for your platform. If you were lucky, the project's INSTALL file gave you hints on how to correctly set the make variables, and told you what libraries it depended on. If you were unlucky, you found out when make failed, and still couldn't tell whether it needed a library you didn't have or was just looking in the wrong place. I often complain about build systems being hard to use as a developer, but for a user it's definitely got much easier. A proliferation of build systems is better than none at all.
I disagree that multiple build systems make it easer for the user. This is I think an oxymoron. A common configure/build system is easier almost by definition.
The second reason is simply that it doesn't matter if projects use different build systems, because they very rarely need to communicate with each other. The only cost in using projects with different build systems is that you have to have all their build systems installed rather than just one.
I am a member of the user class. Multiiple install methods mean that in addition to becoming skilled at using the programs themselves one must become reaquainted with the details and the gotchas of a particular build method every six months or so. I use TeX, Scribus, Gimp, Krita, Inkscape etc. in my publishing endeavours. Six months from now will I remember that the packaging system used by Inkscape works better in command line mode from a gui window than from a console session? Will I be able to find the email that tells how to use cmake for Scribus? Is it KDE or Koffice that I have to reinstall to upgrade Krita? And so on. The genius of Unix has always been that if you knew how to manipulate one Unix you were 90% familar with running another. The genius of Open Source software has always been that you downloaded the tarball, ran ./configure, make and make install and it worked every time (barring missing libraries of course). You never even had to read the install guide.
I don't expect to change the course already decided on for Inkscape. But it comes with a cost for the user. And ultimately that will hurt acceptance of the product. There is more than one package I have downloaded where the build process and the unexpected dependencies wove such a tangle that I gave up and went on to something else.