Re: PATCH: Use GNU Makeisms to simplify libgcc build

[Mark Mitchell <mark at codesourcery dot com>]

On Thu, 2003-08-28 at 23:40, Alexandre Oliva wrote:
> 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.  

Well, that's true.  But, it did indicate that the SC had made a
decision, and it did invite your reply.  We had no way of knowing.

> > There does not need to be any single feature.  
> 
> There hasn't been any so far.

I'm testing a patch which will chop another big chunk of lines out of
the Makefile.  It uses pattern rules and "$<".  Now, it may well be that
it is actually portable.  But -- unlike you, who know all about all of
these various portability issues -- I do not *know* if it is portable.  

I don't want to know.

I want to build a better compiler.

Now, I do know that it works with GNU make.

The fact that requiring GNU make *automatically* makes the Makefiles
portable is enough reason to use GNU make right there.

You seem to think the burden is to justify requiring GNU make.

I believe it is quite the opposite -- you need to justify *not*
requiring it.

Having said that, I am not going to debate this issue with you.  We
debated it in Ottawa; the consensus was GNU make.  The SC debated it
again; the consensus was GNU make.  As far as I'm concerned, this issue
is closed.

If you want to reopen the issue, petition the SC directly.

> > 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?  

You have an opinion; I have a different opinion.

Yes, the make variables are now implicit.  

However, there's no chance you'll forget to pass them if you add a new
recursive submake.  And, empirically, someone *had* forgotten to pass
them before.

If some recursive call *doesn't* want "AR_FOR_TARGET" set to the
archiver for the target system, it should explicitly reset the value. 
That is the abnormal case.

(Really, someone should figure out how to avoid recursive make
altogether, but that's a bigger project.)

Despite my feelings to the contrary, if the other build machinery
maintainers agree with you that my patch is not a net improvement, I
will respect that and you may revert the patch without further
complaints from me.

> 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?

No -- by counting the Makefiles that get pulled in from other
directories.

[mitchell@doubledemon gcc]$ wc -l `find . -name 'Makefile.in' -o -name
'Make-lang.in'`
   2526 ./ada/Make-lang.in
   2165 ./ada/Makefile.in
   3966 ./Makefile.in
    288 ./cp/Make-lang.in
    549 ./f/Make-lang.in
    141 ./fixinc/Makefile.in
    467 ./java/Make-lang.in
    158 ./objc/Make-lang.in
     29 ./testsuite/treelang/Makefile.in
    329 ./treelang/Make-lang.in
  10618 total

But, I don't care if it's 10,000 or 2830; it's too many either way.

> > Using GNU make will let us shrink that considerably.

My first patch already dropped the line count.

The next one -- if I finish it -- will do even more.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com