Akim Demaille <[EMAIL PROTECTED]> writes:
> >>>>> "Raja" == Raja R Harinath <[EMAIL PROTECTED]> writes:
> Raja> Hi, Akim Demaille <[EMAIL PROTECTED]> 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 ------------------------------ [EMAIL PROTECTED]
"When all else fails, read the instructions." -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing." -- Roy L Ash
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
