What is minimum set of Automake work files needed for distribution on github?

[Robert Parker]

I need to meet the requirements of 2 sets of users, the ordinary user who
is only interested `./configure; make; make install` and the power users
who want to start with `autoreconf`.

So far google search on the topic has only increased my confusion.

[Eric Blake]

Post by Robert Parker
I need to meet the requirements of 2 sets of users, the ordinary user who
is only interested `./configure; make; make install` and the power users
who want to start with `autoreconf`.
So far google search on the topic has only increased my confusion.

The most common solution: don't store anything but configure.ac and
Makefile.am in git.

The power user checks out git, and runs 'autoreconf' to bootstrap the
project, then runs 'make dist' to create a self-contained tarball.

The ordinary user takes a tarball, unpacks it, and runs './configure;
make; make install' without needing any autotools installed.

Ordinary users therefore do NOT use direct git checkouts. Working with
git is reserved for power users.

[Robert Parker]

Thanks, that does make sense.

Post by Eric Blake

Post by Robert Parker
I need to meet the requirements of 2 sets of users, the ordinary user

who

Post by Robert Parker
is only interested `./configure; make; make install` and the power users
who want to start with `autoreconf`.
So far google search on the topic has only increased my confusion.

The most common solution: don't store anything but configure.ac and
Makefile.am in git.
The power user checks out git, and runs 'autoreconf' to bootstrap the
project, then runs 'make dist' to create a self-contained tarball.
The ordinary user takes a tarball, unpacks it, and runs './configure;
make; make install' without needing any autotools installed.
Ordinary users therefore do NOT use direct git checkouts. Working with
git is reserved for power users.
--
Eric Blake eblake redhat com [phone]
Libvirt virtualization library http://libvirt.org

[John Calcote]

Hi Robert,

The Autotools were created to meet a specific need - that of the open
source distribution model supported by many open source projects where,
occasionally - or perhaps nightly, the project maintainers would release a
source tarball containing a configure script and Makefile.in files. As a
regular user, you'd want to just download a tarball, extract, and run
./configure && make.

However, as a potential contributor, you'd want the source repository so
you could create patches against the tip of a particular branch. So you'd
clone the source repository and use the Autotools to create a configure
script for yourself in your repository work area.

Thus, the usual technique is to commit the Autotools source files required
by your project, but to NOT commit a configure script. Anyone wanting to
clone your repository is expected to be "developer enough" to know how to
run "autoreconf -i" to create the configure script.

While you CAN commit a configure script, it generally causes more problems
than it solves, as you find yourself committing an updated configure script
for lots of little project changes. Regardless, many projects do this -
especially lately on projects hosted by github, mainly (I believe) because
github has defined a new trend in the open source world where "regular
users" tend to get the source from the repository rather than from a
tarball, more often than not these days.

Here's a resource you might find helpful:
http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool


John

Post by Robert Parker
I need to meet the requirements of 2 sets of users, the ordinary user who
is only interested `./configure; make; make install` and the power users
who want to start with `autoreconf`.
So far google search on the topic has only increased my confusion.
--
The Bundys, Cliven, Ted and Al. Great guys to look up to.

[Bob Friesenhahn]

Post by John Calcote
Thus, the usual technique is to commit the Autotools source files required
by your project, but to NOT commit a configure script. Anyone wanting to
clone your repository is expected to be "developer enough" to know how to
run "autoreconf -i" to create the configure script.

The main problem with this is that not all users wanting to build from
sources in the repository have the correct autotools versions. Even
if they do have the correct autotools versions, the sources may have
been hacked by an OS Autotools package maintainer to work differently.

Due to these problems, the configure script for my package provides
the --enable-maintainer-mode option, and I use a method of updating
the package version which does not require editing configure.ac
(avoiding re-generating configure). Whenever someone commits to the
repository, I rebuild all of the additional generated files enabled to
be updated via --enable-maintainer-mode.

Bob

[Russ Allbery]

Post by Bob Friesenhahn
The main problem with this is that not all users wanting to build from
sources in the repository have the correct autotools versions. Even if
they do have the correct autotools versions, the sources may have been
hacked by an OS Autotools package maintainer to work differently.

This doesn't work for all projects, but I've had a lot of success in the
past in automating the process I use to generate a tarball release (which
might be as simple as make dist), and just run it daily or weekly and
publish the resulting tarballs somewhere. That lets people who really
want to run source repository snapshots still have a distribution-ready
tree that doesn't require autotools.

I intensely dislike committing autotools output to the repository. It's a
matter of taste, honestly, and some people just do that, but I hate large,
generated files in version control since they're often not mergable and
cause all sorts of irritating issues on branching, commits from systems
with slightly different tool versions, etc.

[Robert Parker]

Thanks guys for your well considered replies.
You gave me plenty to think about.
Presently my github projects have everything that make dist generates.

Clearly the consensus is strongly against doing that so in time I will
reduce my github repos to your recommendations.

I still want to distribute tarballs for those who want to work that way. I
have a web site doing just about nothing right now so I think I'll upload
the tarballs there.

Bob

Post by Russ Allbery

Post by Bob Friesenhahn
The main problem with this is that not all users wanting to build from
sources in the repository have the correct autotools versions. Even if
they do have the correct autotools versions, the sources may have been
hacked by an OS Autotools package maintainer to work differently.

This doesn't work for all projects, but I've had a lot of success in the
past in automating the process I use to generate a tarball release (which
might be as simple as make dist), and just run it daily or weekly and
publish the resulting tarballs somewhere. That lets people who really
want to run source repository snapshots still have a distribution-ready
tree that doesn't require autotools.
I intensely dislike committing autotools output to the repository. It's a
matter of taste, honestly, and some people just do that, but I hate large,
generated files in version control since they're often not mergable and
cause all sorts of irritating issues on branching, commits from systems
with slightly different tool versions, etc.
--

[Peter Johansson]

Post by Robert Parker
I need to meet the requirements of 2 sets of users, the ordinary user who
is only interested `./configure; make; make install` and the power users
who want to start with `autoreconf`.
So far google search on the topic has only increased my confusion.

The minimum set is 'configure.ac' and 'Makefile.am', but we typically
have the m4 files under version control as well to avoid the requirement
that the right version should be available in a location where aclocal
can find it. Then we usually add some text files also, such as 'README'
and definitely 'COPYING'.

hth,
Peter