Bugzilla – Bug 256
further standardizing autoconf usage
Last modified: 2004-11-24 22:54:21
You need to log in before you can comment on or make changes to this bug.
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.
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.
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.
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?
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
Actually, you can just run config.status to update a Makefile: llvm/config.status <relative path of Makefile> 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.
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.
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
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).
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.
> 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
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.
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
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
Is this bug still meaningful? -Chris
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.
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.