[Top][All Lists]

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

Re: Shell functions pointlessly specialized on _AC_LANG_ABBREV

From: Eric Blake
Subject: Re: Shell functions pointlessly specialized on _AC_LANG_ABBREV
Date: Mon, 16 Sep 2013 14:38:47 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8

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_LANG([C])
>     AC_CHECK_HEADERS([stddef.h])
>     AC_LANG([C++])
>     AC_CHECK_HEADERS([cstddef])
> 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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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