Confused about configure script and Makefile.in

Question

I'm currently learning how to use the autoconf/automake toolchain. I seem to have a general understanding of the workflow here - basically you have a configure.ac script which generates an executable configure file. The generated configure script is then executed by the end user to generate Makefiles, so the program can be built/installed.

So the installation for a typical end-user is basically:

./configure
make
make install
make clean

Okay, now here's where I'm confused:

As a developer, I've noticed that the auto-generated configure script sometimes won't run, and will error with:

config.status: error: cannot find input file: `somedir/Makefile.in' 

This confuses me, because I thought the configure script is supposed to generate the Makefile.in. So Googling around for some answers, I've discovered that this can be fixed with an autogen.sh script, which basically "resets" the state of the autoconf environment. A typical autogen.sh script would be something like:

aclocal \
&& automake --add-missing \
&& autoconf

Okay fine. But as an end-user who's downloaded countless tarballs throughout my life, I've never had to use an autogen.sh script. All I did was uncompress the tarball, and do the usual configure/make/make install/make clean routine.

But as a developer who's now using autoconf, it seems that configure doesn't actually run unless you run autogen.sh first. So I find this very confusing, because I thought the end-user shouldn't have to run autogen.sh.

So why do I have to run autogen.sh first - in order for the configure script to find Makefile.in? Why doesn't the configure script simply generate it?

Spite

GNU Autoconf (or perhaps GNU Automake) comes with a convenient autoreconf script that does the same thing as autogen.sh and more. As for why you need to run it, do you have a Makefile.am in the somedir subdirectory for Automake to find somedir/Makefile.am and generate somedir/Makefile.in from it? – Mcgarry

If there is an autoreg.sh script, then run it. If not, then run autoupdate && autoreconf -f -i. Both should produce a configure for you to run. It is sad it is not clearly stated in the Autotools manuals, but it is par for the course with Autotools. By the way, I believe autogen.sh is a wrapper script for autoreconf -f -i (maybe with a verbose option). – Steerage

Answer 1

In order to really understand the autotools utilities you have to remember where they come from: they come from an open source world where there are (a) developers who are working from a source code repository (CVS, Git, etc.) and creating a tar file or similar containing source code and putting that tar file up on a download site, and (b) end-users who are getting the source code tar file, compiling that source code on their system and using the resulting binary. Obviously the folks in group (a) also compile the code and use the resulting binary, but the folks in group (b) don't have or need, often, all the tools for development that the folks in group (a) need.

So the use of the tools is geared towards this split, where the people in group (b) don't have access to autoconf, automake, etc.

When using autoconf, people generally check in the configure.ac file (input to autoconf) into source control but do not check in the output of autoconf, the configure script (some projects do check in the configure script of course: it's up to you).

When using automake, people generally check in the Makefile.am file (input to automake) but do not check in the output of automake: Makefile.in.

The configure script basically looks at your system for various optional elements that the package may or may not need, where they can be found, etc. Once it finds this information, it can use it to convert various XXX.in files (typically, but not solely, Makefile.in) into XXX files (for example, Makefile).

So the steps generally go like this: write configure.ac and Makefile.am and check them in. To build the project from source code control checkout, run autoconf to generate configure from configure.ac. Run automake to generate Makefile.in from Makefile.am. Run configure to generate Makefile from Makefile.in. Run make to build the product.

When you want to release the source code (if you're developing an open source product that makes source code releases) you run autoconf and automake, then bundle up the source code with the configure and Makefile.in files, so that people building your source code release just need make and a compiler and don't need any autotools.

Because the order of running autoconf and automake (and libtool if you use it) can be tricky there are scripts like autogen.sh and autoreconf, etc. which are checked into source control to be used by developers building from source control, but these are not needed/used by people building from the source code release tar file etc.

Autoconf and automake are often used together but you can use autoconf without automake, if you want to write your own Makefile.in.

Civic

From your description, a Makefile.am is not needed in the dist tarball. I just tried building a program from its dist , I rm Makefile.am and make exited with error make: *** No rule to make target 'Makefile.am', needed by 'Makefile.in'. Stop. – Prohibition

I don't know where you got the idea that it's not needed. Autoconf was created for free software packages and a dist tarball for a free software package should contain all the files that are needed to modify it and rebuild it, and that includes Makefile.am. If the user wanted to modify the code they would install autotools, make the change, and rebuild, so they need all those extra files in the dist tarball. The goal is to ensure they don't have to install autotools, if they don't want to modify the software. – Civic

Good explaination. Thanks for saving me hours! – Jaunita

Answer 2

For this error:

config.status: error: cannot find input file: `somedir/Makefile.in'

In the directory where the configure.ac is located in the Makefile.am add a line with the subdirectory somedir

SUBDIRS = somedir

Inside somedir put a Makefile.am with all the description. then run automaker --add-missing

A better description can be found in 7.1 Recursing subdirectories automake manual. https://www.gnu.org/software/automake/manual/automake.html

Pipeline