Re: new Erlang macros for testing for modules, functions, etc.

[Romain Lenglet]

On Saturday 08 August 2009 00:49:36 Paolo Bonzini wrote:
> On 08/07/2009 03:54 PM, Romain Lenglet wrote:
> > Here is a series of patches for 1) fixing the command line used for
> > AC_RUN_IFELSE so that the run fails if the module doesn't compile (patch
> > 0001), and 2) adding 4 new macros to test for modules, functions, and
> > headers (patches 0002-0004) with their doc and tests.
>
> I committed the first.

Thanks!

> For the others, I'd like to understand from the maintainers what is the
> plan for 2.64.1/2.65, and in any case I'd rather see it use the language
> dispatch mechanism (e.g. AC_LANG_PUSH(Erlang) and then use AC_CHECK_FUNC
> normally, or something like that).  But I have not read the patches
> beyond the changelogs, so the latter remark might be unapplicable or
> otherwise stupid.

Yeah, I'd like to see that too. There are some challenges.

First, in some languages, features can be tested just by compiling / linking 
(AC_COMPILE_IFELSE / AC_LINK_IFELSE), cf. AC_CHECK_FUNC, while in others it 
must be tested by running (AC_RUN_IFELSE) as the linking is done at runtime, 
cf. AC_ERLANG_CHECK_FUNC. For now, only the Erlang support will require such 
subtleties, but if someone adds support for Python we would have the same 
problem with Python tests. How to cleanly support such differences between 
languages in a single function?

We already have such problems with AC_COMPILE_IFELSE, which doesn't work with 
Erlang because this macro assumes that a language generates object files 
(named *.$ac_objext), which is not the case in Erlang.
I think I could fix it in Erlang by just doing "touch conftest.$ac_objext" if 
the test module compiles (and I will send a patch to do that if this trick 
works), but that's very ugly and we need a more general solution.

I'd like also to implement an AC_DEFINE that works to generate Erlang headers. 
But I'm afraid that making AC_DEFINE (and AC_CHECK_FUNC et al.) context 
dependent would break existing configurations, e.g.:
AC_PUSH_LANG(Erlang)
... # test some Erlang features...
AC_DEFINE([HAVE_BLAH], [1]) # define a *C* macro
AC_POP_LANG(Erlang)
There is probably no code doing that now, but we can't be sure.
I agree that we may not have the same problem with usages of AC_CHECK_FUNC 
(for example) in between AC_PUSH_LANG(Erlang) and AC_POP_LANG(Erlang), as it 
would be ugly and wouldn't make much sense, but possible usages of AC_DEFINE 
like above make sense and should be taken into account.

Are we ready to break backwards compatibility by making those macros language-
context-dependent?
Or should we use a different namespace for those language-context-dependent 
macros? And redefine the existing AC_CHECK_FUNC, etc. as aliases for the C-
specific macros, like having AC_CHECK_FUNC rewriting into:
AC_PUSH_LANG(C)
AC_CHECK_FUNC_NEXT_GEN([$1], ...)
AC_POP_LANG(C)

--
Romain Lenglet