Another paralell make patch for libf2c
Tue Oct 6 02:26:00 GMT 1998
>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 $(LIBG2C)
>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.
In short, in an earlier snapshot of egcs, the `all' rule did not
depend on $(LIBG2C), and, AFAIK, it shouldn't. But, I recognize that
I don't have the full picture, not really understanding the new
multi-lib stuff. (I should probably have questioned an earlier patch
I saw that made the change to the `all' rule, but since it was by
the author of the multi-lib stuff, and the explanation seemed
reasonable, I didn't take the time to check it out myself.)
I thought the idea of the pre-multilib libf2c Makefile rules was to
distinguish its `all' rule from its `$(LIBG2C)' rule -- the former
being to build .o's, the latter being to build the .a, with the
top-level libf2c `all' rule doing the recursive `make' to make both
happen. A recent patch seems to have changed this somewhat, and I
believe that contributed to breaking parallel builds of libf2c.
But, by themselves, stamp files do not, AFAIK, need to have dependencies
if they are depended upon only by rules whose commands explicitly
invoke recursive makes that *do* have the requisite dependencies
for those stamp files. (Which I believe is clearly the case for
lib[FIU]77.) However, there's a caveat for parallel makes (and
it just makes "general sense" to me regardless of any special
treatment for the case): if the stamp files in question are depended
upon by rules that *also* depend upon other rules that "assume" the
stamp files are already updated, then that's a problem...and I believe
the patch preceding HJ's might have created this problem.
That's why the most recent patch by HJ didn't make sense to me,
and my not having the most recent snapshot with the previous patch
integrated (though I do have a copy of the patch itself) led to
my not really understanding what was going on.
The previous patch I'm unsure about, in terms of its implications,
* Makefile.in (all): Correct dependencies do --disable-multilibs
(I've reformatted the ChangeLog entry as it appeared in the patch;
presumably it is more complete/correct in the CVS tree itself.
Also, `do' should be `so'. My bad for not looking at this more
closely when it was originally submitted -- I glossed over it since
it seemed like reasonable follow-up to the multi-lib work.)
>Without the dependencies nothing stops the rules for LIBG2C from being issued
>before the subdir makes are complete. At least that's my take.
>I can certainly revert the patch if you still desire.
I would still desire. We might have to revert another, earlier patch,
until there's a clearer explanation of what is going on.
In particular, a clearer understanding, by all interested parties --
not just myself and Dave Love -- might result in making similar fixes
in non-g77 areas to reduce the likelihood of people like HJ running
into the same bugs over and over again when trying things like
parallel makes. (Which wouldn't be surprising, given how much copying
of methods for these sorts of things seems to take place between
libraries, e.g. g77's and Chill's.)
>ps. I agree totally with your other comments. Far better for HJ to explain
>the patch when he submits it instead of making us guess.
More frustratingly, HJ just intimated to me in private email that it
was my fault this happened, because I made the changes that broke
parallel make without knowing GNU make. (I believe neither charge
is true, even though I do think my not looking into the earlier patch
might have contributed to breaking parallel builds of libf2c, but
that's beside *this* point.)
I have no concern that the submitters of other patches, that might
break a few things while adding new features, will take
responsibility for their mistakes and learn from them.
However, since HJ's response to these repeated expressions of concerns
is to blame, and call into question the expertise of, others, I have
very great concerns that he isn't going to take responsibility for
*his* mistakes and thus learn from them.
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. We'll try to do better about looking into them and
following up appropriately and quickly, but this episode shows
how much time and energy gets wasted when a patch of his is
installed *before* he, or someone else, volunteers to actually
Generally, I'd prefer if nobody modified any egcs code without
getting it exactly right 100% of the time. Given that there's no
real likelihood of that happening, and that *nobody* on this list
is an expert in all the relevant technologies (or, if they are,
they're too busy to check every patch for perfection themselves),
it makes sense to allow people to submit patches that make a fair
attempt to improve the code while accounting for the fact that
many *other* people, without the exact same expertise as they,
have to be able to understand what's going on.
Since I do not consider myself an expert on GNU make (pretty much
the same way as I consider myself less than an expert on C, Fortran,
compilers, operating systems, computer architectures, and so on -- the
sorts of things people hire me to work on at great expense :), I
don't expect everybody else to be an expert on it.
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.
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.
tq vm, (burley)
More information about the Gcc-patches