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