Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

further standardizing autoconf usage #628

Closed
llvmbot opened this issue Feb 26, 2004 · 20 comments
Closed

further standardizing autoconf usage #628

llvmbot opened this issue Feb 26, 2004 · 20 comments

Comments

@llvmbot
Copy link
Member

llvmbot commented Feb 26, 2004

Bugzilla Link 256
Resolution FIXED
Resolved on Feb 22, 2010 12:42
Version trunk
OS All
Depends On llvm/llvm-bugzilla-archive#257
Reporter LLVM Bugzilla Contributor
CC @lattner

Extended Description

Our use of autoconf today is not that of a 'standard' autoconfiscated program.
This causes several things not to work as expected, mainly building with a
srcdir != builddir.

We should change all our Makefile's into Makefile.in's. This will have the
following advantages:
a) We can stop using LEVEL and use the more standard (and easier to
develop for) srcdir and top_srcdir variables. Using LEVEL is error prone,
especially when you move a Makefile to another directory.
b) It will make including a common Makefile easier. Instead of
explicitely including a Makefile in our Makefile.in I think it would be better
to define a variable for the to-be-included files and have autoconf rewrite it
in the resulting Makefile (I wonder if this is doable with normal make
variables?). This will make changes like the one I made for the SPEC
benchmarks much easier (it will only require a single line change in
configure.ac instead of editing all the Makefiles under
SPEC/{CINT2000,CFP2000} to include Makefile.spec2000 instead of
Makefile.spec).
c) A simple rule to automatically remake Makefile from a Makefile.in
will allow changes to Makefile.in in srcdir to be propageted to builddir
without rerunning configure. This does not work with the current setup.

@llvmbot
Copy link
Member Author

llvmbot commented Feb 26, 2004

I couldn't agree more.

The only thing I would add is that also using automake would standardize the
makefile targets and shorten the amount of specification in makefiles while also
giving us some hard-to-write targets like "dist-check" which checks a
distribution of the project after it has been built (i.e. verifying you can
correctly build the distribution from the sources put in a tarball). This issue
is covered at length in bug 106. Also see bug 105 for more info about autoconf.

@llvmbot
Copy link
Member Author

llvmbot commented Feb 26, 2004

Unfortunately using automake will involve a lot more work. With this bug I am
trying to balance the improvement/change ratio so that the change is not a
major amount of work but just enough to give us some improvements in the build
system.

@llvmbot
Copy link
Member Author

llvmbot commented Feb 26, 2004

Our build system used to copy over all Makefiles during the configure process.
However, we changed it because adding new Makefiles required modifying the
configure script, and the configuration process took a long time because LLVM
uses a deep nesting structure with lots of Makefiles (which is unusual for
most autoconf projects that we've seen). Rerunning configure was especially
painful on the slow Sparcs, and with the old setup, we were re-running configure
all the time.

To fix this, I made the Makefiles copy over subdirectory Makefiles during the
build. This greatly reduced configure time and made changes to configure.ac
much less frequent.

So, if you're going to make changes, I'd recommend that you not make any changes
that require the Makefiles to be filtered through autoconf, as that will
increase both the number of times we need to modify configure.ac and the amount
of time config.status takes to run.

It seems to me that the build system has reached a point (aside from some of the
minor bugs) where it needs to be left alone or seriously refactored. What we
have works but is non-standard, slightly cumbersome, and inefficient. All the
proposed changes seem to fix one and worsen the other two. Major refactoring
seems to be the only way to fix all three.

Thoughts?

@lattner
Copy link
Collaborator

lattner commented Feb 26, 2004

I totally agree with everything John said. :)

The things that is particularly annoying with the
autoconf-rewrites-all-makefiles thing is that you have to rerun configure
whenever you change a makefile...

-Chris

@llvmbot
Copy link
Member Author

llvmbot commented Feb 26, 2004

Actually, you can just run config.status to update a Makefile:

llvm/config.status

The bigger problem is that:

  1. All Makefiles need to be listed in configure.ac
  2. Changes to configure.ac require users to re-run configure which regenrates
    config.status and re-copies all of the Makefiles (which LLVM has a lot of).

Some shell scripting might get you out of (1), but (2) would still remain: LLVM
(especially llvm/test/Programs) has lots of Makefiles that would all need copying.

@llvmbot
Copy link
Member Author

llvmbot commented Feb 26, 2004

If you're having performance problems on Sparc, it would be useful to start
using AC_CACHE_VAL more to cache the various tests. This can speed up
re-configures immensely as the tests don't need to be repeated.

@lattner
Copy link
Collaborator

lattner commented Feb 26, 2004

The problem on the sparcs is really the disk I/O of copying the makefiles, on
NFS this hurts a lot. I can't believe how bad the NFS implementation is coming
from the inventors of NFS. :(

-Chris

@llvmbot
Copy link
Member Author

llvmbot commented Feb 26, 2004

Just to address the concerns that John is raising:

The problem today:

  1. When you have objdir != srcdir changing a Makefile requires to rerun
    configure (which as John points out takes a lot of time).
  2. Not all subdirectories are created after configure is ran. For example
    configure an objdir somewhere and try to run only SPEC2000 INT tests. I
    haven't figured that out yet since the subdirectories don't exist. It seems
    that I need to run the whole SPEC test suite in order for the subdirectories
    to appear (or maybe guess the Makefiles and do a make CINT2000/Makefile
    maybe?)
  3. When configure.ac is changed all Makefiles are copied again.

With every Makefile being created by configure (from a Makefile.in):

  1. When a Makefile is changed a rule runs config.status on the Makefile.in and
    regenerates just the changed Makefile.
  2. The whole tree is replicated at configure time so the whole tree is
    available in the objdir so you can run any test. The structure of the project
    is more clear too.
  3. Same as before, you just process all Makefiles in configure time.

From the above I think it is clear that changing our Makefiles to Makefile.in
will actually reduce reconfigure times as long as Makefiles are changed more
frequently than configure.in. This is because reconfiguring the whole tree
will not be necessary unless configure itself changes. Doing a small sampling
over the past 3 weeks in llvm-commits suggests that Makefiles are changed much
more frequently than configure.ac (even with the last week being very busy for
configure.ac).

@llvmbot
Copy link
Member Author

llvmbot commented Feb 26, 2004

I have another idea that Chris mentioned a while back: move the tests to another
CVS module. From my "users perspective", I don't really care about the extensive
tests being part of the source code package. I trust that the core developers
test sufficiently what they commit. I want the tests available, but a separate
package/module for them would be ideal This way I could update, autoconf,
compile, and install the LLVM libraries quickly without worrying about the
testing stuff. It would also give you core developers a little more lattitude
in how you design your tests and the makefiles that go with them (e.g. do you
need autoconf at all? your makefiles could be non-standard, etc. etc.).

Splitting the code from the tests would also make automake conversion easier.
Note that when I attempted to do automake on LLVM a couple of months ago I found
that I could convert the source directories fairly easily. Where I got hung up
was all the test directories. If the tests were split from the source code, I
would volunteer to do the automake conversion which would make LLVM a lot easier
to build and more "standard" with other open source packages.

Another alternative is to go 1/2 and 1/2. It would be useful to have some
tests included with the source code just as a sanity check. But, it isn't useful
to have detailed performance analysis tests there. Users want to know that LLVM
works; performance is a secondary issue.

My $0.02 worth.

@lattner
Copy link
Collaborator

lattner commented Feb 26, 2004

move the tests to another CVS module.

Yes, this definitely needs to happen. We want/need to both GROW the tests, and
still not bog down casual LLVM developers. :) Particularly useful about this
would be having a configure script for the test suite, instead of it being
included with the main LLVM one.

Splitting the code from the tests would also make automake conversion easier.

Definitely.

Another alternative is to go 1/2 and 1/2. It would be useful to have some
tests included with the source code just as a sanity check.

Sure. The regression tests, for example, don't use any of the makefile
machinery being discussed, and are small/self contained. They should stay with
the LLVM source tree.

Overall, this is a different subject than the current bug. Perhaps a new bug
should be filed for splitting the CVS tree, and this one could be marked as
dependent on it? Is there already a bug for this?

-Chris

@llvmbot
Copy link
Member Author

llvmbot commented Feb 26, 2004

I think moving tests out of llvm is a great idea that can be implemented
rather easily. We simply move the test subdirectory under a separate module
(named test). Adding this to the toplevel configure:

if test -d $srcdir/test; then
AC_CONFIG_SUBDIRS(test)
fi

will result in the same bahaviour as today if the module 'test' is under llvm
ditribution's $srcdir.

@lattner
Copy link
Collaborator

lattner commented Feb 26, 2004

Just to be clear: test/Programs should be moved, but not test/Regression and
others. Otherwise this sounds fine. :)

Once the trees are seperated, we can even clean up the test/Programs makefiles
A LOT by not relying on the LLVM Makefile.rules file. Using the same
rules for testing as we do for building the source has made the rules much more
complex than they should be in some cases. This is a minor win though.

-Chris

@lattner
Copy link
Collaborator

lattner commented Feb 26, 2004

Changing all of these bugs who do not have people looking at them to be assigned
to "unassignedbugs", indicating that if someone is feeling ambitious, they can
take ownership of the bug.

If I stole your bug, and you still want it, feel free to take ownership back.

-Chris

2 similar comments
@lattner
Copy link
Collaborator

lattner commented Feb 26, 2004

Changing all of these bugs who do not have people looking at them to be assigned
to "unassignedbugs", indicating that if someone is feeling ambitious, they can
take ownership of the bug.

If I stole your bug, and you still want it, feel free to take ownership back.

-Chris

@lattner
Copy link
Collaborator

lattner commented Feb 26, 2004

Changing all of these bugs who do not have people looking at them to be assigned
to "unassignedbugs", indicating that if someone is feeling ambitious, they can
take ownership of the bug.

If I stole your bug, and you still want it, feel free to take ownership back.

-Chris

@lattner
Copy link
Collaborator

lattner commented Nov 15, 2004

Is this bug still meaningful?

-Chris

@llvmbot
Copy link
Member Author

llvmbot commented Nov 15, 2004

yes, its meaningful, but most of what its requesting has been done, avoided, or
is now ill advised. There's still a few cleanups it recommends that I might
do. One way or the other, I'll resolve this for 1.4.

@llvmbot
Copy link
Member Author

llvmbot commented Nov 25, 2004

Resolving this bug because:

  1. srcdir != objdir building is working fine and has been for some time.
  2. automake usage was attempted but it didn't provide enough flexibility for
    the things LLVM needs so it was rejected (see bug 106).
  3. Makefile.in files are not necessary for the LLVM makefile system as all
    configured data is handled through Makefile.config.in.
  4. Automatic makefile updating from the srcdir to the objdir is working
    properly.
  5. The makefile system now knows how to reconfigure automatically if the
    configure script has changed.
  6. The makefile system now knows how to regenerate configured files from their
    sources if the sources change (e.g if Makefile.config.in changes, then the
    makefiles will automatically regenerate Makefile.config)
  7. John's makefile copying strategy has been preserved.
  8. Many more items are now cached to reduce confgure script time when caching
    is enabled (-C option).
  9. The test/Programs has been moved to projects/llvm-test getting rid of a
    a large source of makefile copies.

Patches are too numerous and too spread over time to list here. But, the main
reorganization of the configure.ac script per autoconf guidlines is here:

http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041122/021257.html

Reid.

@llvmbot
Copy link
Member Author

llvmbot commented Nov 26, 2021

mentioned in issue llvm/llvm-bugzilla-archive#257

@llvmbot
Copy link
Member Author

llvmbot commented Nov 26, 2021

mentioned in issue llvm/llvm-bugzilla-archive#33311

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 1, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants