This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Toplevel: more dependency cleanup

DJ Delorie wrote:
1. all-bootstrap depends on all-libiberty.  all-gcc doesn't.  This seems

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

Why?  I'd rather have the dependencies grouped by target, not by
dependency.  I.e. all the "all-binutils:" dependencies should be
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]