Re: CVS Autotools

[Raja R Harinath]

Akim Demaille <address@hidden> writes:
> >>>>> "Raja" == Raja R Harinath <address@hidden> writes:
> Raja> Hi, Akim Demaille <address@hidden> writes:
> >> I'm happy to say that running the test suites of both Libtools and
> >> of Automake with CVS Autoconf works fine.
> 
> Raja> The following simple configure.in seems to be causing problems,
> Raja> with the latest CVS libtool from the multi-language-branch, and
> Raja> CVS autoconf.
> 
> Raja>   AC_INIT
> Raja>   AC_PROG_LIBTOOL
> Raja>   AC_PROG_CXX
> Raja>   AC_OUTPUT
> 
> The way Libtool changes some Autoconf macros is doomed to failure.  We
> can't proceed this way.  Something must be decided.  I'd suggest that
> we target, after 2.50 and 1.4, some release of Autoconf together with
> Libtool, adjusted one for the other?
> 
> Autoconf will provide hooks where Libtool needs them, but we can't
> continue with Libtool redefining internals.  And I'm very afraid this
> is not doable when targeting both 2.13 and 2.50.

OK.  But, this problem isn't due to the redefining.  I can repeat it
with

  AC_INIT
  AC_PROG_CXXCPP
  AC_OUTPUT

I get 

  configure.in:3: error: AC_LANG_ASSERT: current language is not C++:  C
  ../../aclang.m4:988: AC_PROG_CXXCPP is expanded from...
  configure.in:3: the top level

The documentation does not specify that AC_PROG_CXXCPP has to be
invoked as

  AC_LANG_PUSH(C++)
  AC_PROG_CXXCPP
  AC_LANG_POP

which is redundant, and not backward compatible.  I think you should
remove the AC_LANG_ASSERT, and revert to AC_LANG_PUSH/AC_LANG_POP in
the AC_PROG_*CPP macros.

- Hari
-- 
Raja R Harinath ------------------------------ address@hidden
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash