The current instructions for using autoconf with LLVM are:

0. Don't ever run aclocal.
1. Make sure you have autoconf-2.57, the exact version, installed.
2. Go to the top directory and do:
   'gmake configure AUTOCONF=/path/to/autoconf257'
3. Still in the top directory, run:
   'gmake include/Config/config.h.in AUTOHEADER=/path/to/autoheader257'
4. Inspect the 'cvs diff include/Config/config.h.in' output
   to make sure that no one has checked in important edits that
   autoheader can't automate

While step 4 will continue to be a good idea, the rest of it doesn't follow the
typical/standard/usual guidelines for using aclocal/autoconf/autoheader. In
particular, the current approach has the following concerns:

1. Makefiles are built by configure so there is no way (or should be no way) to
   run a "configure" target from make. The only way this can work is (a) if you
   already ran configure and (b) configured in your source tree. In the first
   case (a), you won't have "configure" if you're starting from scratch with the
   project. In the second case (b), we're forcing developers who use autoconf
   to always build in the source tree. This is neither desireable nor wise.

2. The omission of using aclocal means that the aclocal.m4 file must be manually
   kept up to date. Any new macros resulting from (a) upgrading to a new version
   of autoconf or (b) adding new statements to configure.ac will require manual
   changes to aclocal.m4.  Admittedly, this doesn't happen often, but that's all
   the more reason to do it .. because you'll forget what needs to be done when
   it does come time to do it. We should discover why it is necessary to omit 
   the use of aclocal and simply permit it.  The trick is to use acinclude.m4
   for the project specific macros. This keeps them out of aclocal.m4 which
   aclocal could change.

3. Keeping the process simple will help new developers who must make config
   changes get through the process more easily.  Case in point: I've been using
   autoconf for about 5 years and I couldn't figure out how to do it with LLVM
   without being told.  The process should be as simple as:
       aclocal
       autoconf
       autoheader
   with only very minor deviations from this.  A "bootstrap.sh" file could be
   written that encapsulates the process and does what is necessary to correctly
   build the configure file.

This bug isn't so much of a bug as it is a "task" that needs to get on someone's
to do list (probably mine).  Before venturing down that road, however, I'd like
feedback from other folks since I'm new to the project.

This bug is all yours, just make sure everyone is in agreement about what to do.
 I totally support making the autoconf system work better, especially if there
is some solution to the "have to copy all of the makefiles to build OBJROOT !=
SRCROOT" problem. :)

-Chris

aclocal is part of automake. Using it is probably fine, but we must remember to
document automake as a (bootstrap) dependency if we decide to use it.

Okay, when it comes time I'll assign it to myself and accept it.

I'm not going to do anything until I hear from John Criswell. Hi John :)

Regarding not copying the Makefiles to OBJROOT, the solution there is automake.
I've written build systems for 20 years and automake is the best I've seen both
from an ease of use and feature/functionality point of view. But, automake is an
entirely different subject, worthy of another bug for discussion sake. I'll open
one.

Brian: current usage of aclocal is limited to automake but it is a general tool
that can be adapted for use by other "build automation" tools. Supposed one day
we come up with "autocompiler" .. how would you ensure that the end user's
project has all the right macros? The answer is aclocal.

This bug has largely fixed itself -- aclocal, autoconf, and autoheader are now
all used. (Funny how things change!) I wrote a script that runs them, and passes
them all the right args, called autoconf/AutoRegen.sh. The bogus stuff in the
top-level Makefile that calls autoconf is gone. I documented aclocal (from
automake 1.4p5 or later) as a build dependency. 

http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040202/011312.html
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040202/011313.html
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040202/011314.html

I hereby declare the usage of autoconf no longer awkward. If you disagree,
feel free to reopen this (and suggest further patches!)

There should be a note added to the release notes as well...

Thanks for taking care of this bug Brian!

-Chris