Problems compiling on NetBSD/m68k
Alexandre Oliva
oliva at dcc.unicamp.br
Sat Feb 20 11:57:32 PST 1999
On Feb 20, 1999, Godmar Back <gback at cs.utah.edu> wrote:
>> Well, the problem can't be related with automake, because it just
>> doesn't have anything to do with configure.
> That's good to hear. What I wondering though is what are macros such as
> AM_INIT_AUTOMAKE, AM_MAINTAINER_MODE, AM_PROG_LIBTOOL, AM_CONDITIONAL, and
> AM_CONFIG_HEADER doing in configure.in if it doesn't have anything to do
> with automake?
AM_INIT_AUTOMAKE just looks for autoconf, automake, aclocal,
autoheader and makeinfo. AM_MAINTAINER_MODE does not test anything,
just enables or disables maintainer support. AM_PROG_LIBTOOL does not
have anything to do with automake, it has to do with libtool.
AM_CONDITIONAL is not a test, it's a kind of AC_DEFINE for Makefiles.
AM_CONFIG_HEADER is just an alternate form of AC_CONFIG_HEADER that
creates the stamp files automake uses. See, no new tests from
automake. There's one from libtool, though, and this maybe a
concern.
> The truth is that the introduction of automake came with significant
> changes to configure.in (see rev 1.47 vs 1.48). It is not at all unlikely
> that configure now does tests it didn't use to do, and that this causes
> problems Nicholai is seeing.
In fact, several tests could be *removed* from configure.in, and it
was an overall major simplification. But it is indeed possible that
some new test performed by *libtool* (not automake) is causing him
trouble. That's why I'm asking.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
More information about the kaffe
mailing list