Index: [thread] [date] [subject] [author]
  From: WHS <wouters@cistron.nl>
  To  : ggi-develop@eskimo.com
  Date: Mon, 20 Jul 1998 14:58:04 +0200

Re: libggi dependencies

Jon M. Taylor wrote:

>         This is absurd.  I have no problem accomodating those who do not
> wish to switch shells, C compilers, make utils or other such fundamental
> tools.  I have a BIG problem with people who will not install a very
> useful tool that does not disturb their existing environment.  autoconf is
> THE standard way to implement cross-platform-Unix building and installing
> of source packages, and I'll be damned if I'll accept junking it just so
> that someone does not have to run any GNU stuff on their system.  And of
> course THEY won't be the ones to spend time hacking together a substitute,
> right?  What nerve!

Calm down.

The point here is that when kgi is in the *BSD kernel, the base part of
libggi (=what's needed to run a standard libggi application on kgi, i.e.
none of the other targets) will be essential for the system and hence be
part of the source tree of *BSD. Then, it makes a lot of sense to
require not having to use GNU stuff to configure.

But, if base-libggi does get into the source trees of the respective
BSD's (subject to the decision to put libggi, at least the base, under
non-copyleft), then obviously, for that base part only a system specific
config is needed (i.e. a script specifically for OpenBSD/FreeBSD/NetBSD
which will be in their source tree). I think there's no problem with
autoconf for anything else.


Btw 1, I'm still waiting for the decision on the libggi license (won't
work on kgi porting until that's settled).


Btw 2, Am I alone in thinking the autoconf way is wrong ? Each
application does some tests now (which sometimes takes quite a while)
which can be settled once and for all by installing a OS-patchkit and
then requiring that to be installed on a machine where such a autoconf
program needs to be compiled. This would also avoid the huge conigure
script that each app using it needs (typ. 60K).

Wouter

Index: [thread] [date] [subject] [author]