Re: Toplevel: more dependency cleanup

[Nathanael Nerode <neroden at twcny dot rr dot com>]

DJ Delorie wrote:
> > 1. all-bootstrap depends on all-libiberty.  all-gcc doesn't.  This seems
> > wrong.
>
> gcc depends on other things which depend on libiberty (like as and
> ld), but go ahead and add the extra dependency anyway.
Yeah, that lets make behave better; all actual dependencies should be 
listed, so that if we later drop another dependency we don't lose any 
real dependencies which were only encoded implicitly.  In particular, 
see below.

> > 2. There aren't any actual dependencies on all-build-libiberty.  I think
> > there should be, most likely.
>
> Before, all the all-build-* were done before the host things.  At
> least, they're supposed to have been.  GCC uses it at the moment.
> There may be others.
>
>
> > (I'm not sure exactly how libiberty is used by gcc, so I'm not sure of the
> > right way to correct this.)
>
> gcc has a few programs it builds that run on the build machine.  It
> needs a build-libiberty to do this.  So, gcc's build depends on
> all-build-libiberty, but only if build != host (if build == host, the
> host libiberty is used).
Rrrright.  OK.

> > 	* Makefile.tpl: Separate dependencies on libiberty; move *-target
> > 	targets.
>
> Why?  I'd rather have the dependencies grouped by target, not by
> dependency.  I.e. all the "all-binutils:" dependencies should be
> together.
Actually, there is a good reason for this, apart from my being able to 
tell which ones are bogus more easily. :-O

A number of dependencies are only semi-real.  For instance, the 
dependency of all-gcc on all-gas is only real if gas is present, being 
configured and built; otherwise it's a waste of make time (and prevents 
use of real dependencies, and prevents the elimination of about fifty if 
statements).  Accordingly, I want to arrange it, eventually, so that 
"soft" dependencies such as that one are present in the Makefile *only* 
when the depended-on module is being configured.  I can make configure 
clever enough to do this fairly cleanly.  (If you can figure out how to 
do it *really* cleanly rather than just *fairly* cleanly, please tell 
me!)  In order to sort this out, the correct sort order is by 
depended-on project.

This doesn't actually apply per se to libiberty, which is a hard 
dependency and is present in every project which uses it.  In this case 
I did it because I find it a lot more readable.

Normally I agree with you about putting all the x: y z dependencies 
together.  In this case the practicalities of my intended changes mean I 
have to think about them the other way, so I'd rather write them the 
other way.

> > +all-bfd: all-libiberty
>
> bfd doesn't depend on libiberty.  bfd is a library.  As for the rest,
> have you actually checked to see if they use libiberty?  Of course,
> it's safe to leave the dependencies in...
Nope, haven't checked.  This was a rearrangement so that it was obvious 
which were *claiming* to use libiberty.  The next step is, of course, to 
make it a correct list.  Libiberty is one of the easiest ones to check 
dependencies of, thankfully.

> > +all-target-fastjar: all-target-libiberty
> > +all-target-gperf: all-target-libiberty
> > +all-target-libstdc++-v3: all-target-libiberty
> > +all-target-libf2c: all-target-libiberty
> > +all-target-libobjc: all-target-libiberty
> > +all-target-winsup: all-target-libiberty
>
> libstdc++, libf2c, and libobjc are libraries.  They shouldn't need to
> depend on all-libiberty. (again, safe to leave it in for now)
I will look into all of these; I don't know what was going on when this 
stuff was written, but it was probably just plain old error.

--Nathanael