Re: Shell functions pointlessly specialized on _AC_LANG_ABBREV

[Eric Blake]

On 09/16/2013 09:52 AM, Zack Weinberg wrote:
> While poking at something else, I happened to notice that we seem to be
> defining redundant copies of many shell functions, one for each language
> under test.  Concretely, if you do this:
> 
>     AC_INIT([test], [0.0.0])
>     AC_CONFIG_HEADERS([config.h])
> 
>     AC_PROG_CC
>     AC_PROG_CXX
> 
>     AC_LANG([C])
>     AC_CHECK_HEADERS([stddef.h])
>     AC_LANG([C++])
>     AC_CHECK_HEADERS([cstddef])
> 
>     AC_OUTPUT
> 
> the generated configure script will contain functions named
> 'ac_fn_c_check_header_compile' and 'ac_fn_cxx_check_header_compile' (and
> also 'ac_fn_c_try_compile' and 'ac_fn_cxx_try_compile') whose bodies are
> character-for-character identical, and both of which depend on the
> variables set and reset by AC_LANG to control the compiler actually in
> use.  It looks like it has been this way since the shell functions were
> introduced back in 2008.
> 
> What was the intention, here? Right now it seems to me that it would
> make most sense to remove _AC_LANG_ABBREV from the function names (so
> there would be just one of each, and it would still depend on the
> current AC_LANG setting).

I think the original goal was to ensure if there ARE any language
dependencies on the function bodies, that we have the right setup to
differentiate between them.  But you are welcome to try and patch things
to use fewer functions if they really did end up being identical in a
project that targets both languages.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature