Many thanks to u for enlightening me !

I wonder if anyone can suggest a simple autotools tutorial?

you want http://sources.redhat.com/autobook/

I tried reading and it still seems too complicated for me. I would like to see a diagram of what files I have to write, their syntax, and how to build a project that consists of a few source files and uses a library (i.e. #include <pthread.h>).

http://www.lrde.epita.fr/~adl/autotools.html ->
http://www.lrde.epita.fr/~adl/dl/autotools.pdf - slides.

But the whole thing isn't simple because it reflects real world mess.

Also, free your mind from 'make' and remember that the main challenge is building dependency tree which can be automated only for limited category of task.

Even in simple case like

where FOO is defined not in another file, but on command line (e.g. a 'configure' argument) you can't know for sure on which of the two 'foo.h', 'bar.h' files your target depends.

The situation is even more hopeless if some portions of code are autogenerated by other tools and/or in not C/C++ only projects.

'make' as a tool comparing file modification dates and running commands is very secondary in the whole picture.

autoconf is the more difficult one to get going. automake is painfully easy, and libtool is just a script you copy to your project so automake will work for libraries.

automake requires Makefile.am files, which merely define variables to tell it what to build out of what, and it will generate a Makefile.in, a makefile template. autoconf requires configure.ac, which tells it what tests to run (e.g. check for a header) and what makefiles to make. It creates a configure script, which runs the requested tests, determines how to call the compiler, etc., on the machine it's being run on, then inserts its findings into the Makefile.in to create a makefile. Once you have your Makefile.am, you can run autoscan to create configure.scan, a "guessed" configure.ac.
Kevin Barry

I am reading the GNU Make manual and I decided to try to make a "universal" Makefile that uses the compiler to figure out dependencies. This seems to work, but I need to figure out how to make it tolerate having sources in another directory.

autoconf and libtool are set up once for the project, no matter how large. At worst, you'll have to add a line to configure.ac to check for an additional system header or lib or add a line to specify another makefile to generate, but that's about it. After that, you just write a Makefile.am like this:
http://svn.berlios.de/wsvn/rservr/tr...ho/Makefile.am
http://svn.berlios.de/wsvn/rservr/tr...ex/Makefile.am

Note that the first has 9 direct local includes and who knows how many secondary, none of which are in the same directory as the .c file, and gcc isn't necessary to determine what they are, allowing this to compile on nearly all *nix. Packaging is also taken care of.
Kevin Barry

See the vpath directive.

Not trying to put you down, but I think my earlier posted makefile does everything yours does while being cleaner and simpler. In particular I would recommend using -MMD instead of -MM, since it saves time (eg: doesn't make dependencies when running make clean).

I was trying to read the GNU make manual to figure out how it works, because I even still hardly understand the syntax.

I don't even see how your Makefile even creates the .d files!

And I am still thinking whether I should be using something like CMake or autotools, but they are so complicated that they make almost no sense whatsoever to me. And in case I might want to eventually share a program it might be more important to use a build system.

Passing -MMD to gcc causes it to create the .d files while it compiles. automake does it the same way.

At the start your programs will be simple so you can use a simple makefile. You can learn about more complicated systems later, when you have more programming experience and the makefile system doesn't provide enough features to build the more complex programs you are working on. Some people share programs without using autoconf, for instance the wmii window manager is built with just make, no autoconf.

So the -MM flag causes it to print out a Makefile line, and -MMD causes it to create a .d file that has a gcc command with the same flags?

So it's OK if everyone's using gcc?

And is it really hard to convert a project consisting of a large amount of source files to a different build system?

Also I wonder what is the remommended way of organizing the different types of files? I know .c and .h files should go to src, what about .o, .d, and executable files?

libc is usually more of a portability problem than gcc; however, I've had code "break" from one version of gcc to the next because of changes in compiler strictness. I wouldn't assume you'll get a predictable result across all versions of gcc.

Once you wrap your head around autotools and get autoconf intstalled into the project it's really easy to convert. The problem with setting up autoconf is it requires certain placeholder files (e.g. README) to be there and there are a few things I never remember that I have to look up. It's a one-time thing for the project, though, which is why I always have to look it up (info autoconf is as good a place as any.) You really don't need to put much in configure.ac if you don't want to, if you hadn't planned on checking for headers and libraries. With Makefile.am, you need to remember that it's all relative to the build directory (where ./configure is run from,) not the location of Makefile.am. Other than that, you wtire a lot less than you would writing the makefile by hand, even with the method you're trying to use (if you included all the install/uninstall code.)
Kevin Barry

The main problem is that many of the tutorials I find just don't work. I try to do what is says but it gives errors.

Also many of the tutorials either use one source file or use things like yacc, etc that I don't understand and my project won't use.

Why isn't there just a simple tutorial that just uses more than 1 source file and actually works?

As I already wrote, complexity of tutorials reflects real world mess.