My problem with make and autoconf, as a young student, was the difficulty of finding quality, intermediate examples. Textbook examples were trivial, professional examples were too dense to understand. There was nothing to bridge the gap.
Trying to read the configure scripts and Makefiles for software like Apache httpd server was overwhelming. There's obviously many man-months of work there as well as unknown styles, conventions, and tricks.
How (and why) would I go from "gcc -lexample -o program csci201.c" and maybe a simple Makefile to a 10,000-line ./configure script? I never had any idea.
The files you want to be reading are configure.ac (formerly configure.in) and Makefile.am. configure is compiled from configure.ac via m4 (no, really) and Makefile.in is compile from Makefile.am by perl. Makefile.in is used to generate Makefile at the end of ./configure (by config.status, actually).
Some configure.ac files are a bit hairy, usually because they depend on heaps of optional packages or because they test for all this obsolete stuff that autoscan told them to.
Have a look at libfake437[1], MudCore[2] or libtelnet[3] for some in-between examples.
The reason you couldn't find a quality, intermediate example of autoconf is that there is no such thing; it's an obtuse and painful tool. As someone else mentioned, cmake is a much better choice.
Does it even make sense to use a GUI IDE to write and build something as cross platform as Apache? All that boiler plate from the IDE is great, but much of what one would consider boiler plate in the Apache code base was built up over time as features were added and it was ported to new platforms.
Right, I basically picked apache randomly. Pretty much any significant open source project from the era I was a student (1997-2001) has the same problem, from a student's point of view anyway.
The problem was that an intermediate student who can use gcc and make but has questions like "what's the best way to organize my source code into directories?" there were no good answers if you were stuck at the command-line with man pages. If you didn't have a good mentor, you were figuring it out for yourself, or trying to emulate a random open source project with hundreds of source files organized into multiple subtrees with helper files, shell scripts, dozens of libraries and modules, and huge configure files that bear no resemblance whatsoever to any problems you're actually trying to solve. Or, maybe, if not a big project, then another intermediate developer who was just as clueless as you and you don't actually want to be imitating.
Meanwhile, GUI-heavy IDEs were offering sane default answers for those intermediate questions and offering tools to help manage a moderate number of dependencies, build steps, and platform targets. Unfortunately, they were also hiding important details and too often became crutches for people who didn't understand how compiling and linking actually works.
I contend that things like "the best way to organize my project into directories" is something that is discovered, and changes, over time while building a project and is specific to that project and the people working on it. Obviously, students don't know this, but they should be writing code, and working toward this discovery, rather than fretting what to name the directory where library routines are stored as The One True Way™.
Trying to read the configure scripts and Makefiles for software like Apache httpd server was overwhelming. There's obviously many man-months of work there as well as unknown styles, conventions, and tricks.
How (and why) would I go from "gcc -lexample -o program csci201.c" and maybe a simple Makefile to a 10,000-line ./configure script? I never had any idea.