4 ms·
My problem with make and autoconf, as a young student, was the difficulty of finding quality, intermediate examples. Textbook examples were trivial, profession
by Goladus 14y ago
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.
- segmond 14y agodo you want to know how to understand it? one line at a time! as a programmer and a non UX guy, i cringe when i see css files with ridiculous amount of rules. being the cheap person i'm and deciding to tackle a layout redesign myself. i started studying css, and understanding it one line at a time, by the time i was done reskinning my site, i had a whole bunch of stylesheets with about 4000 lines. It then dawned on me, that's how I figured out Make files and the config scripts. I started by writing 5 line makefiles, and one day, uh oh, what's this 2000 line file?
- joelthelion 14y agoFortunately there are better build systems available nowadays. CMake is a lot easier on the beginner, and yet it is used by large projects like KDE.
- joe_the_user 14y agoSadly, my experience with CMake makes miss the otherwise annoying make. This is mostly from trying to compile tar balls that used it. It didn't seem to give error messages for missing parts as well as simple make.
- padraigm 14y agoThe 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.
- thwarted 14y agoDoes 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.
- Goladus 14y agoRight, 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.
- thwarted 14y agoI 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™.
- endgame 14y agoThe 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. [1]: http://code.google.com/p/libfake437/source/browse/#svn%2Ftrunk http://code.google.com/p/libfake437/source/browse/#svn%2Ftru... [2]: https://github.com/endgame/MudCore https://github.com/endgame/MudCore [3]: https://github.com/elanthis/libtelnet https://github.com/elanthis/libtelnet