autoconf-patches
[Top][All Lists]
Advanced

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

Re: Improve AC_REPLACE_FUNCS


From: Eric Blake
Subject: Re: Improve AC_REPLACE_FUNCS
Date: Thu, 25 Feb 2010 16:52:14 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

[revisiting another old thread; see here for the original patch]
http://lists.gnu.org/archive/html/autoconf-patches/2009-09/msg00076.html

According to Paolo Bonzini on 9/16/2009 5:39 PM:
> On 09/16/2009 11:37 PM, Eric Blake wrote:
>> It gives a reduction
>> in size by using more AC_CHECK_FUNCS_ONCE instead of inline function
>> checks,
>> and can reduce forks by using a literal rather than a shell variable
>> in more
>> places; particularly when doing AC_REPLACE_FUNCS([a b]).
> 
> No, this breaks if AC_REPLACE_FUNCS is used within a conditional.
> However, since we do not support (pfew...) non-literal $1, using
> AC_CHECK_FUNC to reduce forks is fine now that we are using shell
> functions, like
> 
> m4_define([_AC_REPLACE_FUNC],
> [AC_CHECK_FUNC([$1, [AC_LIBOBJ([$1])])
> ])
> 
> This should expand to just four lines per function.  It won't give a
> size reduction but it would noticeably reduce forks.

Hmm.  I originally read your reply as a rejection of the entire patch; but
kept it marked in my inbox to revisit.  Now, on closer re-reading, I see
that you were only worried about the change in semantics caused by using
AC_CHECK_FUNC_ONCE causing an unconditional check for a function where it
used to be guarded by shell conditionals.  In which case, your proposed
helper function is indeed no semantic change, fewer forks, but not as good
at code reduction.  So, here's what I'm looking at pushing, after testing
(gnulib already overrides AC_REPLACE_FUNCS, so this will probably require
a followup patch there before most gnulib-using projects see a similar
improvement).

By the way, AC_CHECK_FUNC is insufficient (it doesn't define HAVE_FUNC);
but AC_CHECK_FUNCS generates efficient output with single-literal input.
But I may decide to use the former with a copy of the HAVE_FUNC logic, if
that proves to be faster at m4 time than the current approach of making
AC_CHECK_FUNCS is acting on a single-element list.

> 
> I should polish up my patches introducing AC_FOREACH, but that would be
> after 2.65.

Or even after 2.66?  It looks like we both have a bad habit of starting
experiments then forgetting to push them upstream. ;)

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

Attachment: autoconf.patch256
Description: Text document

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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