Should I include configure and makefile in a github repository?

Question

We recently moved from subversion to git, and then to Github, for several open source projects. Github was nice in that it provided a lot of functionality. One of the things I particularly like is the ability to download tags as zip or .tar.gz files.

Unfortunately Github recently discontinued downloads. That shouldn't be a problem because of the ability to download tags. However in the past we have not put a Makefile , configure script or any other autoconf-generated files into the repo because they get lots of conflicts when people merge.

What's the proper way to handle this?

• Should I put autoconf and automake-generated files in the repo so people can download tags directly?
• Or should there be a bootstrap.sh file and people are told to run that?
• Or should I just do a make dist and put that into the repo?

Thanks

Warlike

The accepted answer seems like it misses the point. It seems like there are better answers available. – Scalade

Answer 1

The second is better: you want any user of your repo to be up and running as fast as possible, re-generating what he/she needs in order to build your program.

Since Git is very much a version control for text (as opposed to an artifact repo like Nexus), providing a way to generate the final binary is the way to go.

Shayn

Thanks. That's what I have been doing, but lots of users are confused. – Warlike

@Warlike would a big README help them to get started? – Shayn

The second option (including a bootstrap.sh that runs automake and autoconf) is a bad idea, as this requires users to have the GNU Build System (Autotools) installed in order to build and run your software. This defeats the entire purpose of Autotools, which is to make your source portable across systems—including those for which Autotools is not installed or not available! @Jack_Kelly's answer is correct: You need to release the output of make dist, if necessary somewhere other than GitHub. – Fatherly

Answer 2

Publish the output of make dist via GitHub Releases

Your first option—putting the Autoconf- and Automake-generated files into the repository—is not a good idea. It's almost never beneficial to store generated files in source control. In this case, it's going to pollute your history with a lot of unnecessary and potentially conflicting commits, particularly if not all your contributors are using the same version of Autotools. Your third option—checking in the output of make dist—is a bad idea for exactly the same reasons as the first option.

Your second option—adding a "bootstrap" script that calls Autoconf and Automake to generate the configure scripts—is also a bad idea. This defeats the entire purpose of Autotools, which is to make your source portable across systems—including those for which Autotools is not available! (Consider what would happen if someone wanted to build and install your software on a machine on which they don't have root access, and where the GNU Build System is not installed. A bootstrap script is not going to help them because they'd first need to make a local installation of Autotools and possibly all its dependencies.)

The proper way of releasing code that uses Autotools is to produce a tarball with make dist (or better yet, make distcheck, since this will also run tests and do other sanity checks), and then publish this tarball somewhere other than the source repository.

Your original question, from April 2013, states that GitHub discontinued download pages. However, in July 2013, GitHub added a "Releases" feature that not only pre-packages your source tags, but also allows you to attach arbitrary files to each release. So on GitHub, the Releases page is where you should publish your make dist tarballs (and preferably also the detached GnuPG signatures of them).

Basic steps

1. When you are ready to make a release, tag it and push the tag to GitHub: $ git tag 1.0 # Also use -s if desired $ git push --tags
2. Use your Makefile to produce a tarball: $ make dist # Alternatively, 'make distcheck'
3. Visit the GitHub page for your project and follow the "releases" link:
4. You will be taken to the Releases page for your project. The first time you visit, all you will see is a list of tags and automatically produced tarballs from the source tree: Press the "Draft a new release" button.
5. You will then be presented with a form in which you should fill in the Git tag associated with the release and an optional title and description. Below this there is also a file selector labelled "Attach binaries by dropping them here or selecting them". Use this to upload the tarball you created in Step 2 (and maybe also a detached GnuPG signature of it). When you're done, press the "Publish release" button.
6. Your project's Releases page will now display the release, including prominent download links for the attached files:

If you don't want to use GitHub Releases, then as pointed out in a previous answer, you should upload the tarballs somewhere else, such as your own website or FTP site. Add a link to this repository from your project's README.md so that users can find it.

Fatherly

Answer 3

When you cut a release, upload the result of make distcheck to your project's download page: it's a makefile target that builds the tarball and verifies that it installs, uninstalls, passes tests and other sanity checks. Github being wrong-headed isn't an excuse: create a tree like this in your repo:

/
/source
/source/configure.ac
/source/Makefile.am
/source/...
/releases
/releases/foo-0.1.tar.gz
/releases/...

For developers, you should not have generated files in source control. Many modern autotooled projects bootstrap fine off an invocation of autoreconf -i.

Hartebeest

This doesn't work on github, because github no longer supports download pages. – Warlike

I said that in my answer. If a tool is being wrongheaded, perhaps you should reconsider use of the tool. – Hartebeest

Lol... How do you get rid of both Autotools and Git? Both are wrong headed. Each are over-engineered, and each makes simple tasks difficult. They are examples of what happens when engineers are allowed to drive requirements. – Scalade

You can upload the results of make dist directly to the releases page. – Sunbonnet