Using git for distribution with autotools

I have been looking about this subject for a while and I think I know all I need about “should I put my autotools generated files in my repo?”. I agree with everyone who says that you should not and include just wat is needed to generate them.

Althought I think this is the right approach for development purposes I write a framework which uses git for version control (in the develop branches) and uses the master branch to distribute the code. My question is, is there an easy way to include in git the same files that will be included in the dist package by autotools?. The idea is that every user who clone the repo can just do the usual ./configure && make && make install procedure and not worry about autogen or stuff. Given the nature of the framework it is a little cumbersome to send tar files and so on and easier for users to clone the repo to use it.
Maybe there is some options in git or some standard gitignore file or something to do this.

  • Looking for a way to store versions in a binary compiled from git repo
  • Git diff ignore
  • How to handle subprojects with autotools?
  • Recommended way to use Autoconf Archive macros and other 3rd party macros
  • How do I prevent autotools from re-generating configure script automatically?
  • Bumping version numbers for new releases in associated files (documentation)
  • Thanks a lot!

  • Branch maintenance in git
  • Efficiently comparing generated code between two Git revisions of the source
  • Create fake commits from graph
  • git am/format-patch: control format of line endings
  • Split git repository while preserving and scoping-down branches
  • Git unable to push to remote repository: “Read-only file system”
  • 3 Solutions collect form web for “Using git for distribution with autotools”

    Many will insist that the autotools generated files should not be checked in. However, with git becoming so ubiquitous, I don’t see the harm in doing so, provided you use the latest stable autotools to generate the files. In fact, I suggest you include them:

    As you point out, this allows someone to simply checkout the project and configure it – otherwise, you need to provide .tar[.bz2] snapshots for people who don’t understand the autotools… and nor should they. The whole idea of the autotools is putting the burden on the developer to minimise the requirements and efforts of the end user.

    e.g., passing shell variables on the command line with ./configure ... and make [install] should be sufficient.

    If someone really wants to rebuild the generated files, you should ensure that something like autoreconf -fvi is sufficient. If more complex steps are required, provide an script. Anyone performing this step must have the autotools installed, and presumably has a better understanding of how they work – e.g., a ‘maintainer-mode’ proficiency.

    I wouldn’t commit any of the autogenerated files. Just ask your users to run autoreconf --install before ./configure && make

    You might have to mkdir m4 before all of that if any of the tools complain about the missing directory.

    Should I put my autotools generated files in my repo?

    You can do both.

    Let the master branch have all the autotools generated files checked in so that people can just clone the repository and run ./configure && make && make install without having to run autoconf et al.
    Then you have another branch, say development, which is “clean” and does not have the files checked in.

    This approach does imply that you end up with two branches that needs to be synchronized with merges which is a little maintenance overhead, but it should be almost impossible to get any merge conflicts since the difference will just be files that exists or not.

    Git Baby is a git and github fan, let's start git clone.