Re: (toplevel patch) Fix multilib.out dependencies and related problems

[Nathanael Nerode <neroden@twcny.rr.com>]

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