<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Thu, 2009-11-12 at 12:31 -0800, Jeremy Huddleston wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Nov 12, 2009, at 08:20, Keith Packard wrote: > Excerpts from Gaetan Nadon's message of Thu Nov 12 05:27:14 -0800 2009: > >> There are two kinds of builds. > > There are probably as many kinds of builds as there are people > building -- people download the tarball because it's an easy way to > get the source code, but then as often as not, end up fixing some > minor thing (otherwise, why are they downloading the source?). I'd > bet that much of the time they're fixing the build process. Making > that harder just because they choose not to use git is just mean. > > And, yes, autogen.sh is a defacto standard across much of the > autobuild world. > > I'm fine with cleaning things up, but I don't see any reason to reduce > usability in the process. I'm really confused why we'd need to ship an autogen.sh when the user can just do 'autoreconf -fvi' and be happy. </PRE> </BLOCKQUOTE> I understand Keith's point better now. Developers obtaining code from tarball will be missing autogen.sh. The confusion comes from the fact that we are not defining the target audience. I tried to do that by talking about two kinds of build and I failed. Consider this real life scenario I just went through to distinguish between a developer and a consumer of a tarball. I downloaded an autoconf tarball from GNU at lower level which my distro did not have. A fresh computer install, limited tool chain. I had never done that before. I used the one well documented build process: ./configure and make install. It worked, no need to read anything, works just like xorg. Had there been an autogen.sh and had I tried it, I would have failed and I would not have had a good opinion of the package. That's the second kind of build I talked about. It's not a special case, to reconfigure a package (autoreconf) you better have the required tool chain. My bias, what I want to protect, is the tarball public interface. It's a matter of choosing between the convenience for developers and the usability for consumers of the tarballs. In my mind there is no right or wrong answer. Note that the automake and autoconf package do not have an autogen.sh. I don't know very well how our tarballs are used. I know distros reconfigure, patch and rebuild. Most likely others add tarball the way I did with autoconf. I am concerned with consistency. There are 220 xorg tarballs without autogen.sh. Thanks Gaetan </BODY> </HTML>