Re: gl_* check do nothing?

[Eric Blake]

On 09/29/2010 09:34 AM, Sam Steingold wrote:
> this part of my configure.in:

You haven't switched to configure.ac yet?

> ==========================
> AC_FUNC_CHOWN
> gl_FUNC_MKTIME
> gl_FUNC_GNU_STRFTIME
> gl_FUNC_STRPTIME
> gl_TIME_MODULE_INDICATOR([strptime])
> gl_GETDATE
> gl_FUNC_STRVERSCMP
> gl_STRING_MODULE_INDICATOR([strverscmp])
> gl_FUNC_UNAME
> gl_SYS_UTSNAME_MODULE_INDICATOR([uname])
> gl_FUNC_STRERROR
> gl_STRING_MODULE_INDICATOR([strerror])

Why are you calling these macros directly?  It's much easier to call a 
single gl_INIT (after gl_INIT_EARLY) to get it all taken care of for you.

> produces this output:
> ==========================
> checking for working chown... yes
> checking for working mktime... (cached) yes
> checking for struct tm.tm_zone... (cached) yes
> checking for strverscmp... (cached) yes
> checking for uname... (cached) yes
> checking whether signgam is declared... yes

The fact that there are some (cached) in that output means that you may 
be missing earlier relevant checks.  Remember, m4 allows rearranging the 
order to meet topological dependencies, all based on AC_REQUIRE and on 
optimizations like AC_CHECK_FUNCS_ONCE; so the configure output does not 
necessarily match the order in which you called macros in configure.ac.

> ==========================
> gl_FUNC_STRERROR
> gl_STRING_MODULE_INDICATOR([strerror])
> ==========================
>
> print NOTHING.

At least, not where you were looking.  But it does print something 
elsewhere in the configure output.

> So, does this mean that gnulib NEVER relies on the system-supplied
> strftime, strptime, getdate, strerror?

Not necessarily.

> how do I get the full list of all functions which gnulib actually
> replaced in the current build?

For all gnulib replacements that follow modern paradigms, the fastest 
way to see what needed replacement is 'grep REPLACE_.\*1 config.log', 
although that may miss out on a few of the older-style function 
replacements (for example, poll didn't show up in that paradigm until 
just this week).

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org