Should I push Makefile.in to git repository?

Question

Using autotools as build system, should we ship Makefile.in (generated by automake) withing distribution? Running make dist puts Makefile.in in archive, so should I push Makefile.in to my git repo?

Answer 1

There is no definitive answer to this, just strongly-held opinions.

The traditional view -- and I think I am justified in calling it this, as it was the operative view where Autoconf and Automake were invented -- was that you should check in the generated files. The rationale for this was twofold.

First, it reduced dependencies for development: you could check out a project and run configure without needing to install autoconf and friends. This was especially important in the bad old pre-Linux days, when the tools weren't installed by default and when package managers were just a dream.

Second, because most source changes don't involve changes to the configury, this reduced a possible source of errors where different developers might have different versions of the tools installed.

The check-it-in approach essentially relies on the use of AM_MAINTAINER_MODE. In fact, this is why this mode was invented.

A different view eventually emerged, which was that such files should not be checked in. I think the rationale for this is also twofold.

First, it is cleaner. I'm sure one can find any number of exhortations saying that only editable files should be committed to source control. And, this makes sense -- derived files can be derived; in source control they are just clutter.

Second, it is not uncommon for the generated files to get out of date in the source tree. This happens because developers forget to enable maintainer mode. Checking in just the source files not only avoids this, but also lets other developers catch any possible bugs from this.

This approach pretty much requires avoiding AM_MAINTAINER_MODE.

To sum up, there is no right answer. Some people, in my observation, prefer one of the arguments above; but neither is truly conclusive, in the sense that both approaches have worked well for multiple serious projects over a very long period of time.