Re: (toplevel patch) Real targets for make

Re: (toplevel patch) Real targets for make

[Paolo Bonzini]

> > So there's still autogen resistance. :-)
>
> M4 rates "OK" for tasks that are too complex for C preprocessing
> macros, but not very much too complex.  It's a small window.

You will be happy to know that I agree :-)  I do like autogen,
I would have never thought that something as fixincludes can
be done (and maintained of course!) as M4, not to mention gen*.

But we were speaking of a Makefile, and M4 is a standard
for the build process (thanks? to autoconf), so the idea of a
M4 Makefile.tpl did not look so bizarre to me.  I think that
Makefile.in does belong in that small window.

And, Bruce, it would not look bizarre if Autogen were used to
implement Autoconf!

Paolo (currently compiling Autogen)

Re: (toplevel patch) Real targets for make.

[Robert Dewar]

> You should know that I don't like them either.
> Perl and Python were considered, but Guile won on political considerations.

That's too facile. There are very good technical reasons for preferring
Guile to Perl and Python. There are very good technical reasons for preferring
Python to Perl and Guile. In my opinion (opinions may very), there is no
good technical reason for preferring Perl in this language group :-)

Re: (toplevel patch) Real targets for make.

[Bruce Korb]

Nathanael wrote:
> Paulo wrote:
> >I would not mind (and might give it a try if I knew it would 
> >be considered good) rewriting Makefile.tpl into Makefile.m4.
> 
> So there's still autogen resistance. :-)  I should cc: Bruce Korb,
> but I won't.

Good.  I wouldn't want to know this.

> I actually quite like autogen, even though I'm not terribly fond of 
> LISP, Scheme, or Guile.

You should know that I don't like them either.
Perl and Python were considered, but Guile won on political considerations.

>  I think autogen does a cleaner, better job of 
> autogenerating files than any other tool I've used, including m4 
> (although m4 is OK).  

Thanks, but I disagree on the "OK" for M4.  M4 rates "OK" for tasks
that are too complex for C preprocessing macros, but not very much
too complex.  It's a small window.

> Personally, I'd probably start replacing most of the gen* programs with 
> autogen-driven scripts if they didn't need to be extremely portable 
> (which they do).

I'd have done similar several years ago, but for that very problem.
However, AutoGen is fairly portable.  There are some who have gotten
it working on Windows platforms.  God bless 'em.  :-)

> In my semi-long-term plans is a replacement Automake built atop autogen.

That's also on my "when I have copious spare time" list....

> So please don't take away my Makefile.tpl. :-)

:-)

Cheers,
	Bruce

C.F.: http://gcc.gnu.org/ml/gcc/2002-11/msg01137.html

Re: (toplevel patch) Real targets for make.

[DJ Delorie]

> I would not mind (and might give it a try if I knew it would be
> considered good) rewriting Makefile.tpl into Makefile.m4.

Please don't.  We're already in the middle of work on this file, and
changing its language now would be very disrupting.

Re: (toplevel patch) Real targets for make.

[Paolo Bonzini]

> [moving the changes to Cygnus configure to binutils and gdb]
> will happen.  That patch is coming soon; most of the current
> patches are to prepare for that step.

That's great news.

> Autogen is never run automatically, so this should not be a problem.
> Only maintainers who edit the toplevel Makefile need to run autogen.

Of course.  But then, editing the toplevel Makefile is much more common than
editing the gcc fixincludes scripts (the other task that currently requires
Autogen).  I would not mind (and might give it a try if I knew it would be
considered good) rewriting Makefile.tpl into Makefile.m4.

Paolo

Re: (toplevel patch) Real targets for make.

[DJ Delorie]

> Is it possible/planned/impossible to move the changes to Cygnus
> configure to binutils and gdb as well (and then possibly even
> autoconfiscate them at the same time, dumping Cygnus configure at
> last)?

It will happen.  That patch is coming soon; most of the current
patches are to prepare for that step.

The only reason it hasn't happened in src yet is because it's being
done on a branch in gcc.  If we don't mind unsync'ing src and gcc for
a while, we could start introducing the changes in src now.

> This would introduce the autogen dependency on binutils and gdb as
> well...

Autogen is never run automatically, so this should not be a problem.
Only maintainers who edit the toplevel Makefile need to run autogen.

Re: (toplevel patch) Real targets for make.

[DJ Delorie]

> Is it possible/planned/impossible to move the changes to Cygnus
> configure to binutils and gdb as well (and then possibly even
> autoconfiscate them at the same time, dumping Cygnus configure at
> last)?

It will happen.  That patch is coming soon; most of the current
patches are to prepare for that step.

The only reason it hasn't happened in src yet is because it's being
done on a branch in gcc.  If we don't mind unsync'ing src and gcc for
a while, we could start introducing the changes in src now.

> This would introduce the autogen dependency on binutils and gdb as
> well...

Autogen is never run automatically, so this should not be a problem.
Only maintainers who edit the toplevel Makefile need to run autogen.

Re: (toplevel patch) Real targets for make.

[Bonzini]

> That  change -- configuring host subdirs in the Makefile -- is
> the last serious change needed before autoconfiscation

Is it possible/planned/impossible to move the changes to Cygnus
configure to binutils and gdb as well (and then possibly even
autoconfiscate them at the same time, dumping Cygnus
configure at last)?

This would introduce the autogen dependency on binutils and
gdb as well... could it be an idea to rewrite Makefile.tpl in m4?
It does not seem to use advanced autogen constructs.

Paolo Bonzini

Re: (toplevel patch) Real targets for make.

[Bonzini]

> That  change -- configuring host subdirs in the Makefile -- is
> the last serious change needed before autoconfiscation

Is it possible/planned/impossible to move the changes to Cygnus
configure to binutils and gdb as well (and then possibly even
autoconfiscate them at the same time, dumping Cygnus
configure at last)?

This would introduce the autogen dependency on binutils and
gdb as well... could it be an idea to rewrite Makefile.tpl in m4?
It does not seem to use advanced autogen constructs.

Paolo Bonzini