On Tue, Aug 21, 2007 at 01:50:04PM -0400, John R. Culleton wrote:
On Tuesday 21 August 2007, Daniel Hulme wrote:
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.
I wouldn't go as far as saying it's an oxymoron, but it's not what I said. Multiple build systems make it easier for the user, when the alternative is having to configure everything by hand. Obviously, having one Platonic ideal build system would be much easier for the user, but you might as well wish for one all-purpose programming language, or an ideal political system. Having lots, each with its own advantages and shortcomings, is a good intermediate step on the path from having nothing useful to having the perfect 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.
If you have to remember all of that in order to compile the software, the build system obviously isn't working properly. What you're telling me here isn't that there are too many build systems, it's that these particular build systems are too hard to use. Maybe I should write a new one...
The genius of Unix has always been that if you knew how to manipulate one Unix you were 90% familar with running another.
Having had to run an autobuilder that compiled for various Unix-like OSes like Solaris, AIX, and *BSD, of varying ages, I'm not sure I can agree with that. Even today, as a Debian user, if a SuSE or Red Hat user comes to me for help on a system administration task, I probably can't help him.
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.
Perhaps I use different software to you, but it seems to me that as recently as five years ago I still had to hand-edit Makefiles to build from tarred sources. Having a gadget that works out all the correct settings for you is still enough of a blessing to me that I don't mind if I have to prod it a bit.
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.
I'm sorry to hear that. Were there no binaries available for that product? I think people, on the whole, are willing to use the binaries that come with their distribution. (I exclude Windows users, of course, who have to rely on vendor-supplied binaries.) Those who aren't mostly switch to Gentoo, whose ebuilds provide a unified user-interface to build systems in the manner you seem to be longing for.