Another paralell make patch for libf2c

Jeffrey A Law
Tue Oct 6 22:02:00 GMT 1998

First note, I've reverted HJ's patch until we reach a decision about what the
right fix should be.

  In message < >you write:
  > >I believe that by showing that s-libfoo depends on foo that each subdir
  > >(f77, i77, u77) can be built in parallel and that the rules to build $(LIB
  > G2C) will not be issued before the makes in the subdirs are finished.
  > I'm still not sure why the rule to build $(LIBG2C) gets issued before
  > the `all' rule has completely finished -- I believe that was a recent
  > change, but I'm having trouble keeping track.
It has to be issued before "all" because "all" depends on $(LIBG2C).

  > In short, in an earlier snapshot of egcs, the `all' rule did not
  > depend on $(LIBG2C), and, AFAIK, it shouldn't.
Why?  I'm not questioning right/wrong, just trying to understand.

  > I don't find that stance acceptable for g77, so I would appreciate
  > it if his patches to egcs/gcc/f/ and egcs/libf2c/ *not* be applied
  > without explicit, specific approval from myself, Dave Love, or
  > Toon Moene.
Fine.  Consider it policy until you say otherwise.  I've got no problem with

  > But I do expect anybody submitting patches that "fix" something to
  > make a fair attempt to explain what is being fixed, in a way that's
  > fairly easily verified without having to learn all the relevant
  > stuff.  If I don't understand the libf2c stuff, but Dave Love does,
  > for example, that's good enough for me.
Yup.  Agreed 100%.

  > After all, if there's one thing that definitely is true about the
  > egcs project, it's that it is a *cooperative* undertaking, which
  > requires that people *cooperate* in explaining the things they are
  > doing so others can better understand them: cooperation implies
  > fairly strong *communication* even throughout the animal kingdom,
  > AFAIK, and certainly in human endeavours.
Yes.  Which is precisely why I've been trying to get HJ to submit better
patches for the last 14 months.  It is to everyone's advantage if we can
get HJ to submit better patches.


More information about the Gcc-patches mailing list