Re: PATCH: Use GNU Makeisms to simplify libgcc build

[Alexandre Oliva <aoliva at redhat dot com>]

On Aug 28, 2003, Mark Mitchell <mark@codesourcery.com> wrote:

> For the record, you were asked -- by me, at the SC's behest, after a
> 13-0-1 vote in favor of GNU make -- if you objected.

> I asked you that on August 17th.  You did not reply until today.

> I waited until August 26th to make the announcement.

Your message didn't mention any deadline.  I replied on Gerald's
message as soon as I received today, and it reminded me that I'd left
yours behind.  The reason I didn't reply to yours as soon as I
received it was that I found it very insulting that I (and possibly
none of the others who happen to maintain the code the SC was talking
about) were invited to take part in the discussion, or even were
warned that such a discussion was underway and asked to provide
opinions on it.  I didn't want this feeling to get through, so I had
to let the message rest for a while.

> There does not need to be any single feature.  

There hasn't been any so far.

> There are *lots* of good features in GNU make, but the most important
> one is that it behaves in the same way on all platforms.

I only see hand waving here.  Using the make features I posted
probably at least a month ago also gets you the same on all
platforms.

> You are of course free to propose any patches, including ones to remove
> GNU makeisms.

Ok, how about we start with reverting your patch and asking you to fix
the problem properly?  IMNSHO, you fixed the bugs by introducing a
regression, which is that makes that don't support the export command
won't behave correctly.  If the solution was to pass down all
_FOR_TARGET variables down in every make invocation, heck, just do
it.  That's better than removing all the code we had that was almost
there, that we'll have to resurrect as soon as we run into a case in
which we don't want one of these macros to be passed down, at which
point the bug you ``fixed'' would be back.

I don't want GCC's build machinery to become something as convoluted
as glibc's, that makes heavy use of GNU make, and I think that's what
we'll get if we start using GNU make features galore.  I'd rather be
on the safe side and only use them if they're absolutely necessary, or
if they give us significant maintainability gains.  Your patch gives
us none of these.  IMNSHO it is actually worse because it makes the
passing of variables less explicit.  You can't just look at a sub-make
invocation and the macros mentioned it in to see what gets passed
down: you have to look for all exports that might be in the Makefile
(and, IIUC what the plan is, in any other Makefile fragments included
directly or indirectly from it), and if you decide that, at some
point, you don't want to pass a certain macro down, you just can't do
it.

I.e., you're trading a problem that was hard to fix in the short run
for something that might be an unsurmountable problem in the long run,
whose only solution would be to go back to what we had before your
patch and then fix the problem the way it should have been fixed from
the beginning.  You're just setting the time-bomb such that it will
explode in someone else's lap.  I don't want you to do that.  If you
found the problem, and you spent the time to figure out that the
solution was to pass these macros down everywhere, then just do it.
Don't force them to be passed down in the process.

> But we have over 10,000 lines of Makefiles under gcc right now, and,
> quite simply, that's ridiculous.

I can 2830 lines of non-comments in gcc/Makefile.in.  How did you get
to the 10000-line figure?  By counting lines in automake-generated
Makefile.ins in libstdc++ and libjava?

> Using GNU make will let us shrink that considerably.

When I see the patch, I may believe, but I'd appreciate a chance to
comment on it before it gets in.  Feel free to ping me if I'm not
sufficiently responsive.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer