Problems compiling on NetBSD/m68k

Alexandre Oliva oliva at dcc.unicamp.br
Thu Feb 18 09:39:57 PST 1999


On Feb 18, 1999, Godmar Back <gback at cs.utah.edu> wrote:

> Of course, you may argue that's needed for portability.

One of the big advantages of Kaffe is that it's portable.  I can't
think of trying to make it portable without autoconf or similar.

> My take on this is that other people will care about other platforms,

Easy to say that when it's been ported to the platform you work on.
But who was the guy whining when libtool failed to work on FreeBSD
because of a bug in FreeBSD's linker?  Well, it was easy to work
around this problem, but think of yourself trying to port a package as
complex as Kaffe to some platform if it had not been developed with
portability in mind.

> they'll build it there, merge in their changes and that's how portability 
> works in practice and should work in practice.

It might work as you describe, but it's *much* harder for the porter.
Developing portable software isn't easy, but I thank Tim for having
decided to aim at portability from the beginning, despite the
additional complexity.

> Now you have to top it off by learning automake *in addition* to make and

When you learn automake, you usually don't have to learn make, that's
the whole point of automake.  Of course, you may need make rules for
complex actions that automake does not support, but compare the
Makefile.ins we had before the transition with the new Makefile.ams.
I can't believe you think the old Makefiles are easier for *new*
developers (those that were already used to the makefiles are biased)

> autoconf, since automake is for all practical purposes unusable if you 
> don't understand Makefile.in's and Makefiles.

You don't even have to look at Makefile.ins and Makefiles when you use 
automake.

> Simplicity, manageability and maintainability is where the challenge in 
> software engineering lies these days, IMO.

Exactly.  That's the point.

> I don't know what that libkaffevm.lai file is

it's a copy of the .la file with the `installed' variable set to yes,
i.e., it's the .la file that's going to be installed.  It used to be
generated at install time only, but people have complained that they
couldn't run `make install' from a read-only build tree then.

> but every time I'm building Kaffe I'm about to get stomach cramps
> when I see with what suffixes libtool/automake comes up: .la .alx
> .al .ax .nm .nmT .lai, just to name a few.

Don't blame automake for that, it's libtool that comes up with those
suffixes, and they're all hidden used only within the .libs directory, 
that you don't have to care about anyway.

> Kind of makes you long for the times where all you had to put up with 
> were .in, .o, .so and .a files.

Yep, now you have only .am and .la.  Isn't that simpler?

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