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 18:10:35 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Crater Lake)

To make things a little bit clearer, here is what the autoscan you get
at the end of my patches give on Autoconf itself:

/tmp/ace % ./autoscan -A .                                       nostromo 17:51
Name "main::args" used only once: possible typo at ./autoscan line 563.
Name "main::line" used only once: possible typo at ./autoscan line 563.
Use of uninitialized value in string at ./autoscan line 31.
warning: missing AC_PROG_CC wanted by: tests/config.h ltmain.sh:215 
ltmain.sh:357 ltmain.sh:357
warning: missing AC_PROG_CPP wanted by: ltmain.sh:358 ltmain.sh:358
warning: missing AC_PROG_CXX wanted by: ltmain.sh:1864 ltmain.sh:1897 
ltmain.sh:2639 ltmain.sh:2640
warning: missing AC_PROG_LN_S wanted by: Makefile.in:325 tests/Makefile.in:128 
man/Makefile.in:166 m4/Makefile.in:111 doc/Makefile.in:228 doc/Makefile.in:276 
ltmain.sh:405
warning: missing AC_PROG_RANLIB wanted by: ltmain.sh:3989

I will sure address the warnings in a near future.  Since Autoconf
core seems to need still a lot of work, since there are issues I don't
think I'm able to address myself, this leaves me some time to find
back what I completely lost those last months with Autoconf: fun.

Having to release 2.50 is really a pain: there is always something
wrong new showing up :( Fortunately the test suite is getting very
very good IMHO, and really helps us having a shorter cycle.  We are
converging.  

Still, I can't wait til 2.50 is out, so that autom4te be born, and
later, the (*£&$(*& specializing macros.  It's been literally _years_
I want to implement specializing macros in Autoconf, but I must not,
otherwise that would delay again 2.50.

See this for instance

        http://sources.redhat.com/ml/autoconf/1999-02/msg00144.html

if you're curious...  I do recommend that you read it, as this is the
main goal which made me want to be a milli^H^H^H^H^HAutoconf
maintainer.  This is my Autoconf task number one.  Here is, for the
hurried reader, the most interesting snippet:

| Let's go for major feature two.
|
| With the input
|
| | AC_DEFUN(AC_CHECK_FUNC_BEN, [AC_CHECK_FUNC(elliston)])
| |
| | AC_CHECK_FUNCS(ben)
|
| one has
|
| | checking for elliston... (cached) no

i.e., not `checking for ben' as a plain AC_CHECK_FUNCS would have
done: AC_CHECK_FUNCS discovered there was a special check for the
`ben' function.

| and config.h.in holds:
|
| | /* config.h.in.  Generated automatically from configure.in by autoheader.  
*/
| |
| | /* Define if you have the `elliston' function. */
| | #undef HAVE_ELLISTON
|
| i.e., there is automatic macro specialization (it would have been the
| same with AC_CHECK_FUNCS(foo ben bar)).

Still given that autoscan is, as you said, minor in Autoconf, I think
I'm allow to find back some fun with Autoconf toying with autoscan.


Back to the results above: clearly they demonstrate we will need some
means to tell autoscan where *not* to look, typically the test suite.

About LN_S, I must say I don't know why Automake does not use it.
I'll send a message on automake@ about this issue.



reply via email to

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