-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Comments
I couldn't agree more. The only thing I would add is that also using automake would standardize the |
Unfortunately using automake will involve a lot more work. With this bug I am |
Our build system used to copy over all Makefiles during the configure process. To fix this, I made the Makefiles copy over subdirectory Makefiles during the So, if you're going to make changes, I'd recommend that you not make any changes It seems to me that the build system has reached a point (aside from some of the Thoughts? |
I totally agree with everything John said. :) The things that is particularly annoying with the -Chris |
Actually, you can just run config.status to update a Makefile: llvm/config.status The bigger problem is that:
Some shell scripting might get you out of (1), but (2) would still remain: LLVM |
If you're having performance problems on Sparc, it would be useful to start |
The problem on the sparcs is really the disk I/O of copying the makefiles, on -Chris |
Just to address the concerns that John is raising: The problem today:
With every Makefile being created by configure (from a Makefile.in):
From the above I think it is clear that changing our Makefiles to Makefile.in |
I have another idea that Chris mentioned a while back: move the tests to another Splitting the code from the tests would also make automake conversion easier. Another alternative is to go 1/2 and 1/2. It would be useful to have some My $0.02 worth. |
Yes, this definitely needs to happen. We want/need to both GROW the tests, and
Definitely.
Sure. The regression tests, for example, don't use any of the makefile Overall, this is a different subject than the current bug. Perhaps a new bug -Chris |
I think moving tests out of llvm is a great idea that can be implemented if test -d $srcdir/test; then will result in the same bahaviour as today if the module 'test' is under llvm |
Just to be clear: test/Programs should be moved, but not test/Regression and Once the trees are seperated, we can even clean up the test/Programs makefiles -Chris |
Changing all of these bugs who do not have people looking at them to be assigned If I stole your bug, and you still want it, feel free to take ownership back. -Chris |
2 similar comments
Changing all of these bugs who do not have people looking at them to be assigned If I stole your bug, and you still want it, feel free to take ownership back. -Chris |
Changing all of these bugs who do not have people looking at them to be assigned 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 |
Resolving this bug because:
Patches are too numerous and too spread over time to list here. But, the main http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041122/021257.html Reid. |
mentioned in issue llvm/llvm-bugzilla-archive#257 |
mentioned in issue llvm/llvm-bugzilla-archive#33311 |
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.
The text was updated successfully, but these errors were encountered: