Re: automake & autoconf

Date view Thread view Subject view Author view

From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Sat Jan 09 1999 - 07:04:22 EST


On Jan 9, 1999, Godmar Back <gback@cs.utah.edu> wrote:

> What is this distinction about developer vs. other makefiles?
> Shouldn't this be mentioned in the FAQ/FAQ. files?

I think it's mentioned there already, but I may be wrong. The only
important difference is that developer makefiles contain code for
automatic dependency tracking, that depends on gcc and GNU make,
whereas user Makefiles, generated with `make dist', contain the
dependencies collected by the developer's build.

> b) all the sudden subjected us to limitations that we weren't subjected before:
> + like no files from other directories.

This can be easily worked around, and it makes Kaffe more portable.
The VPATH hacks we used were not portable, for instance.

> + like having to use gmake for developing.

I, for one, *always* use gmake; is there anything wrong with it?

> + like not being to link certain libraries.

This has nothing to do with automake; it's a limitation of *various*
operating systems, that libtool hides from its users. I may have
stepped on too early to introduce libtool in Kaffe, since the
inter-library dependency code is not as widely ported as it should,
but Kaffe's approach was very naive, and it would certainly lead to
silent breakage in several systems. The issues involved with linking
a static library into a shared library, or even a shared library with
another shared library, and very subtle and very unportable, and
Kaffe's naive approach worked on some platforms more by luck than
anything else.

libtool completely hides these problems from users in the case of
libraries, but not yet in the case of modules (dlopenable libraries),
because it will sometimes refrain from linking a static library with a
module, and linking the program that dlopens the module with that
static library won't always help, because the symbol may fail to be
imported. We're working to fix these problems; meanwhile, a simple
work-around is to disable the construction of shared modules. This
won't affect Kaffe's ability to dlopen pre-existing libraries, and
will probably make it a bit faster. We could even default to static
modules and shared (where available) libkaffevm.

> How about if we made it such that if you check kaffe out and do a
> ./configure; make, it will work as it used to work?

Did you try that? t works. checkout is not the same as update,
though.

-- 
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


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:33 EDT