[LLVMbugs] [Bug 105] New: Usage Of autoconf Is Awkward

[bugzilla-daemon at zion.cs.uiuc.edu]

http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=105

           Summary: Usage Of autoconf Is Awkward
           Product: Build scripts
           Version: 1.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: autoconf
        AssignedTo: criswell at uiuc.edu
        ReportedBy: rspencer at x10sys.com
                CC: criswell at uiuc.edu,sabre at nondot.org


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.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.