This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: (toplevel patch) Fix multilib.out dependencies and related problems
- From: Nathanael Nerode <neroden at twcny dot rr dot com>
- To: gcc-patches at gcc dot gnu dot org, gdb-patches at sources dot redhat dot com, binutils at sources dot redhat dot com
- Date: Thu, 19 Dec 2002 20:17:16 -0500
- Subject: Re: (toplevel patch) Fix multilib.out dependencies and related problems
I said:
> Removed xgcc and ran 'make'; gcc rebuilt it, and target libs were
> reconfigured and built.
DJ quoth:
>That shouldn't happen. Use move-if-change to update one common
>multilib.out, so that if the list of multilibs doesn't change,
>*nothing* gets reconfigured or rebuilt. We want to trigger a *check*
>when gcc changes, but only actually *reconfigure* if needed.
Uh, yeah. Make isn't designed to realize that you can change a file and
not change the generated file depending on it; this is not an
unreasonable assumption in most cases. To put it another way, I don't
care very much.
>I'm wondering if the common multilib.out target should depend on the
>all-gcc phony target; we kinda want it to run every time we check the
Of course it should. But it can't, it actually can't, because then we
have a real target depending on a phony target, and every target subdir
gets reconfigured every single time. Sorry.
You could try to do this with a phony multilib.out target. Then you'd
need to make configure-target-foo depend on it instead of
(TARGET_SUBDIR)/foo/Makefile. And you'd find that target subdirs would
never get reconfigured. Sorry.
You could patch that problem up by putting the code for foo/Makefile
back into configure-target-foo, and hard-coding yet more things Make
should do, such as determining whether foo/Makefile is out of date.
Maybe this is the preferred method, but I will have nothing to do with
it, since I'm certain it's the wrong direction to go.
>gcc subdir, because we don't know if something else besides xgcc
>affects the specs (which affects multilib.out).
Eeech. We should actually know what affects the specs, you know. :-/
> We can get away with
>this if we use move-if-change.
Kinda, sorta.
Here's a scheme, which might do the trick.
(First note that a common multilib.out is a separate issue and
can and should be done however we fix these other things.)
Have the common multilib.out depend on nothing.
Have the build process for gcc (I hope there's nothing else which
can affect multilib.out...) do the testing and move-if-changing of
multilib.out. Effectively, this is a preinstall; building all-gcc
should build multilib.out directly into the location where the target
subdirs look for it, and the rules for regenerating it will live in the
gcc Makefile.
This should mean that a change in gcc, provided the build process is
used, will change multilib.out.
Happy with this?
If not, here are some other ideas, thrown out at least partly in
frustration:
* Whatever determines the contents of multilib.out should just get its
own damn rule at the top level, rather than messing around with building
the whole of gcc to determine that it's ".;".
* Force every target subdir which actually cares about this to produce
its own copy of multilib.out and to test whether it's out of date on its
own, so that it's out of the hair of the top level.
* Don't support toplevel Make at all.
* Convert the configuration and Makefiles for all subdirectories to
fragmentary Makefile fragments, which are plugged into the top level.
In other words, only support the top level.
* Make all-gcc a real target, similarly for all the others, and require
the subdirs to create the corresponding files name 'all'. This is
actually a pretty good idea, although it's quite non-standard; it
amounts to the total elimination of all phony targets.
* Use existing real targets: in place of all-gcc, use gcc/xgcc gcc/cc1
etc. This of course requires massive and ugly changes to the top level.
--
Incidentally, I now know the one feature I want added to all versions of
Make, and it's not one which exists in any version of make I've seen.
Plus, it's very very simple.
For any target, in addition to being able to specify a command and
dependencies, you should be able to specify an external program to run
in a shell, which gives exit status 0 if the target is up to date and
exit status 1 if the target needs to be rebuilt. (For total
generality, it might require a shell variable to be passed in indicating
whether the dependencies were up to date.) If it returned 1, the
dependencies would still have to be examined to see if they needed to be
rebuilt first, however.
This would deal with virtually all "problems" with Make in a generic
way. For instance, we simply annotate multilib.out with its test and a
dependency on all-gcc. All-gcc is still considered updated every
time, but this doesn't force multilib.out to be.
This actually solves every real issue I have ever seen anyone have with
Make ever, and I am surprised that it hasn't been implemented in any
version I've met. I'm not sure which make variants to push this idea
at...
--Nathanael