Advertisement

Makefile advice request :)

Started by August 29, 2003 11:55 PM
8 comments, last by Feral 21 years ago
Hello hello ! I''d like to pester you all on advice on how `best` to setup a Makefile. (thinking for gnumake, fwiw). Primarilly my question revolves around one make file per directory or one `master` makefile at the top of the source tree. I''m not set on using gnumake fwiw and willy happily entertain other project building ideas (apache ant?). Thanks
I couldn’t tell you, I don''t have the patience to make one myself.

Recursive Make Considered Harmful
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
Advertisement
Some nearly unfounded advice:
My projects were formerly all single-centralized-make-file based projects. As the projects grew larger it became a pain to maintain the centralized make file. Eventually, I decided to go with the more (unix-)traditional one-make-file-per-directory route.

Over all, I am more satisfied with the latter many-make-file approach. One disadvantage I''ve found is that re-generating the make files can take a while sometimes; once the project reaches a certain size it becomes mildly annoying, but luckily you don''t have to do it often. The development of the library (i.e., not rebuilding and installing the whole thing) can actually go quicker if you have setup your directory hierarchy correctly and modify your rebuild and install routine accordingly (use some sense to only rebuild and install the tree that has changed).

Of course, obviously you should consider the GNU build tools to automatically generate your make files and such from simple instructions rather that writing probably-buggy-and-incomplete make files by hand. They take a couple hours to learn to use them properly, but in my opinion it''s worth it. Any newer version of Automake can handle central-make-file or make-file-per-directory approaches.

Automake and Autoconf are your friends. Get them set up correctly, and they''ll automagically take care of dependencies, and the end user only has to type "./configure; make; make install" to build. Granted, it''ll take you a few hours to figure out how to set them up, but they''ll make makefiles much easier to deal with.
The problem is that makefiles generated by ./configure scripts are really a pain in the ass when something goes wrong. Normally if someone releases a good organized makefile within the source, it should be no problem to edit it by hand and add some extra compiler options or to customize it to suit your needs. But a ./configure created makefile is often waaay too complicated to edit it by hand.
Even experienced users don't like editing them when something goes wrong.
My advice: Use handmade makefiles for small+medium projects and automake / autoconf for real big programs that you want to release to a broad public. (John Modal doesn't like editing makefiles. even typing './configure' is almost too much)

[edit] stupid typo.

SwSh website!

[edited by - SwSh on August 31, 2003 4:32:32 AM]
1) with qutomake/conf you never hand alter the makefile, you alter the Makefile.am

2) nothing should ever go wrong with "./configure;make install". if it does its developer''s problem for making a shitty release.

It took me a long time to finally figure out automake, but thank god for it
Advertisement
I''ve only ever had a makefile generated by ./configure go wrong once, and that couldn''t have been fixed by editing the makefile.

While we''re on the subject, does anyone know of a good resource for learning the GNU build system (automake, autoconf, etc.)?
---New infokeeps brain running;must gas up!
There''s always the official manuals (which I think are pretty good at teaching as well as serving as a reference):
Autoconf
Automake
libtool

The only other links I''d give you are turned up on the first page of Google with "Autoconf/Automake/libtool tutorial" anyway .

I also got inspired and spent a few hours trying to learn the GNU build tools with no luck. Three manuals each in the size of a phonebook. Not a single good complete example.
How many maintainers are they? All of them including their favorite stuff that the next maintainer is phasing out.
The number of programs...autoscan, automake, autoconf, aclocal, autoheader and perhaps some more that I forgot or missed. Most of them producing incomplete output that you are supposed to edit with a text editor.

Back to the real power of simply wonderful makefiles!
Does it not exist any simple tool under linux for them that hate writing makefiles?
Recursive make really is harmful.

Autoconf and similar tools are useful for systems that will be ported between many different UNIX-flavor systems, but are useless for single-UNIX systems or highly custom make situations (such as when avoiding recursion).

The ideal is to specify rules in top-level rules files, and specify overrides, file lists, and options in the sub-level make files. Ideally, a "make" in a subdirectory will build only that directory plus prerequisites (with full dependency checking) whereas a "make" at top level will build everything, with full dependencies. Even more ideally, there is no sub-make or forking involved (except for the compiler/linker, of course :-)

Full dependencies are actually fast and the right thing if you don''t do recursive make, but a real pain (and slow) if you fall for the devil of recursion.

Typically, you''ll make use of the double-indirect feature to build various SRC_$(PROGNAME) and OBJ_$(PROGNAME) variables, and a list of the various PROGNAMES, which then end up being concatenated into the full build list.

Oh, and VPATH is inherently a broken concept. Use explicit path re-writing in pattern rules instead.

This topic is closed to new replies.

Advertisement