[PATCH 0/5] xserver: configuration/packaging janitorial maintenance
gaetan.nadon at videotron.ca
Thu Nov 12 14:54:11 PST 2009
On Thu, 2009-11-12 at 12:31 -0800, Jeremy Huddleston wrote:
> 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.
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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xorg-devel