autoconf-patches
[Top][All Lists]
Advanced

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

Re: Playing with autoscan 2.54 on the Coreutils


From: Akim Demaille
Subject: Re: Playing with autoscan 2.54 on the Coreutils
Date: 18 Sep 2002 09:45:48 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

[First bits]

| > From: Akim Demaille <address@hidden>
| > Date: 16 Sep 2002 15:53:01 +0200
| 
| > configure.ac: warning: missing AC_CHECK_FUNCS([dcgettext]) wanted by: 
src/ls.c:1666
| 
| Is such a test needed?  If dcgettext is not a no-op, then we're using
| a sufficiently new version of GNU gettext, which always has dcgettext.

I agree the test is probably not needed.  As a matter of fact, it is
the whole lib/autoscan directory that needs an overhaul.  It's been
too long I worked only on Autoconf, and not on a real C project that
is very demanding on portability issues, so I don't feel I am
competent to modernize these files :(

In the present case, should we

1. have autoscan forget about dcgettext
2. have autoscan suggest AM_GNU_GETTEXT on dcgettext etc?



| > configure.ac: warning: missing AC_CHECK_FUNCS([getwd]) wanted by: 
lib/xgetcwd.c:44
| > 
| > Maybe this is to be fixed?  Instead of checking for getwd when getwd
| > is found, checking for getcwd? (i.e., teach autoscan `getwd =>
| > AC_CHECK_FUNC(getcwd)'.)?
| 
| No, the "right" fix is to modify lib/xgetcwd.c to use HAVE_GETWD and
| HAVE_DECL_GETWD.  This is low priority, though, as everybody has
| getcwd these days.  Perhaps a simpler fix is to drop the use of getwd
| entirely.

We extend autoscan with a means to say `deprecate function, do not use
it'.


| > configure.ac: warning: missing AC_CHECK_FUNCS([mkdir]) wanted by: 
src/cp.c:432
| > 
| > I don't know what to do here.
| 
| Perhaps we need a way to tell Autoscan, "This program assumes that
| mkdir() works; don't bug me about it." 

Well, it spells `AC_CHECK_FUNCS([mkdir])' :)


| Or better yet, modify Autoscan to assume that mkdir() works by
| default, so that people don't have to worry about it.  The existence
| of mkdir() is a safe assumption for GNU apps these days.

I'm not sure I understand what you mean by `modify Autoscan to assume
that mkdir() works by default': autoscan has a list of suspicious
functions, not a list of sane functions.  So are you suggesting that
we ought to remove `mkdir' from the suspicious functions?


| > configure.ac: warning: missing AC_CHECK_FUNCS([nl_langinfo]) wanted by: 
src/sort.c:576
| > configure.ac: warning: missing AC_CHECK_FUNCS([pow]) wanted by: 
lib/strtod.c:172
| > 
| > Is the non portability of pow obsolete?
| 
| "pow" was in 7th Edition Unix (1979).  I suppose some systems may lack
| it (e.g. because they lack floating point) but I wouldn't worry about
| them unless it comes up as a real problem.

:(  I thought the problem was only related to libm vs. libc.  If,
again, this function is sane from the portability point of view, we
should remove it.




reply via email to

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