From: Per Lundberg <[EMAIL PROTECTED]>
Subject: Re: Is automake really good?
Date: 03 Feb 2000 10:04:42 +0100

> I'm not sure if you really should have to do so. Do we really have to
> support older systems? I mean, FreeBSD 2.2.8 is rather old.

  That's a good question. Ignoring old systems is always much easier
than retaining the portability, so I want to ignore obsolete systems
if possible. But there are still a lot of people who are using FreeBSD
2.x. (I can understand why they don't upgrade it, because 3.x was
originally assumed that it would be a temporary release.)

> Anyway... this configuration seems badly broken anyway. If gcc calls
> the wrong linker, how could he compile *any* programs at all? IMO, it
> is his gcc that should be calling the right linker. Working around
> this in GRUB doesn't really solve the problem.

  However, in this case, that really solves the problem... I know
that's a Bad Thing, but "I can do it anyway" is much better than "I
can't do it, never."

> No, perhaps not. But nevertheless, I think it should be used, since it
> easifies the maintenance of the Makefiles humongously.

  I think you have already realized when/where Automake can make your
task easy. If the project is "ordinary" (such as a GNOME application),
it is very, very powerful. You won't worry about anything related to
Makefiles. But if the project is "unusual" and so it requires some
complicated instructions to build it, it is very very poor. How it is
poor can be seen in the document itself. See the example, etags. That
is a relatively simple case, but Automake cannot deal with that
cleanly. I know Automake can now solve that by per-program flags in an
elegant way, but it still has many disadvantages.

> It is? I haven't checked the Automake sources myself, but if what you
> say is true, someone ought to rewrite (those parts) of Automake.

  I don't mean that everyone should throw it away, but we are working
on GRUB but not on Automake. So we should consider what is good for
GRUB rather than what is good for Automake.

----------------------------------------------------------------------
OKUJI Yoshinori  <[EMAIL PROTECTED]>           ^o-o^
http://duff.kuicr.kyoto-u.ac.jp/~okuji (in English)     m /

Reply via email to