[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS Autotools
Raja R Harinath
Re: CVS Autotools
19 Dec 2000 09:48:49 -0600
Gnus/5.0808 (Gnus v5.8.8) Emacs/21.0.93
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
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
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.
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