autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 17-proto-autoscan-check.patch


From: Akim Demaille
Subject: Re: 17-proto-autoscan-check.patch
Date: 22 Jan 2001 17:05:42 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Crater Lake)

| Hello, Akim!
| I was very busy during that last week, so I'm sorry that you didn't have
| my "Ok" for many of your patches.

No problem, I Okay'ed myself a couple of time :)  But really, as an
Okayer I found myself extremely picky, and almost painful.  Had myself
rewrite a couple of patches which were fine from the beginning IMNSHO.

So I'm happy you're back :)

| > ~/src/bison % ../ace/autoscan -A ../ace
| > Name "main::line" used only once: possible typo at ../ace/autoscan line 465.
| > Name "main::args" used only once: possible typo at ../ace/autoscan line 465.
| 
| What version of perl are you using?

What you are reading is the result of the patch I submitted for
autoscan, to have it *check* the completeness of existing configure.ac
in addition of generating configure.scan.

At the beginning it was only for fun, but it was so much fun that I
decided to continue.  This is why although the patch is definitely not
beautiful, I'm asking for an agreement anyway given that the
forthcoming patches make it better.

| > warning: missing AC_PROG_CXX
| > warning: missing AC_PROG_LEX
| > warning: missing AC_PROG_LN_S
| > warning: missing AC_PROG_YACC
| 
| I don't understand what you are running. It's probably an already patched
| version of autoscan, right?
| 
| You have applied a minimal patch. I hope that some of the issues have been
| fixed. Please resubmit your patch for the remaining changes if there are
| any.

What issues?  Have a look at the last messages I sent about autoscan.


| > Pay attention that the path to autoconf is hard coded
| > /home/akim/... (blush).  Some Perl programmer should copy the way
| > autoheader and autoupdate look for autoconf to fix this attrocity.
| 
| I hope that it will not be hardcoded to autoscan.pl and committed on CVS
| :-)

The point is that I am asking to do so.  Yeah, I know.


| 1) it should be optional
| 2) I don't understand what you are trying to extract from it.

autoscan knows what is needed, and can ask to autoconf what is already
checked.  Hence the:

| > warning: missing AC_PROG_CXX
| > warning: missing AC_PROG_LEX
| > warning: missing AC_PROG_LN_S
| > warning: missing AC_PROG_YACC

here, autoscan complains that some macros should be used, and are not.


| > +** Autoscan macros
| > +Can be introduced even before specializing macros.  It just means that
| > +specializing macros will call them.  OTOH, this doubles our work,
| > +since specializing macros will save us from additional typing.  But
| > +the more powerful autoscan is, the better...
| > +
| >  * Autoconf 2.51 or later
| 
| Please put it after "Autoconf 2.51 or later". Autoscan is not an essential
| tool - it will never generate a complete configure.ac, no matter how
| "powerful" it is.

It's been a long time I want to improve autoscan to *check*.  That's
much more important that to generate IMHO.  But the real bonus will
only come once we have specializing macros.  Until that day, too many
things are still opaque to M4, hence to traces.  Nevertheless, given
the bonus this is for the users, we can introduce in autoscan some
glue until specializing macros are introduced.


| >  # Reference these variables to pacify perl -w.
| > -undef %identifiers_macros;
| > -undef %makevars_macros;
| > -undef %programs_macros;
| > +%identifiers_macros = ();
| > +%makevars_macros = ();
| > +%programs_macros = ();
| > +%needed_macros = ();
| 
| I'm surprised. Your Perl must be either very old or very new. I thought
| "undef" is perfectly valid and safe here.

Err, to be honest I just did this because that's what I saw in
automake, and I wanted to be close from Tom's style.

| > +&check_configure_ac ('configure.in');
| 
| How about configure.ac ?

I toyed with Autoconf itself, which, unfortunately, stcuk to stock
Automake, uses configure.in.  But a later patch addresses this.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]