From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Sat, 6 Feb 1999 15:30:37 +0100 (MET)

Re: I have seen the stars... at Creative!

Hi John !

> * LibGGI installs its various shared library binaries into /usr/local/lib,
> but until I added /usr/local/lib to /etc/ld.so.conf I couldn't run
> anything.  KDE added its shared library paths to /etc/ld.so.conf when it
> was installed, perhaps we should do the same?  Obviously there are some
> cross-platform issues involved here, but at least on Linux this should be
> done. 

I think that was discussed a while ago.  I don't remember the reasoning for
not doing so.

A simple approach would be to warn the user, if $prefix/lib is missing from
the ld.so.conf, and suggest to run "make fix-ldconf" to rectify it.

After all, I think it is no big problem, as when distributions start to ship
with LibGGI, the $prefix will be /usr anyway.

> * lib/libggidemos/Makefile is quite incomplete and does not use
> autoconf/automake.  I can fix this now that I am paid to hack GGI all day
> (|->), but I'm not as familiar with auto* as others on this list are, so
> I'll beg off on this one unless no one else wants to do it.

Yeah, that is a bit related to:

> * Some demos are in lib/libggidemos, while others are in
> lib/libggi/programs/demos.  What is the reasoning behind this?

The stuff below libggi/programs is limited to utilities, tests and API
demonstrations, as it is inevitably bundled with LibGGI distributions.

More complex demos should be either packaged separately, or in libggidemos.

The directory holds a bunch of old, "first generation" demos, which are 
horribly coded (by me) for historic reasons, if noone is interested anymore,
we can remove many of them.

The only really cool thing there is 3d.c, most others are outdated,
superseded by newer versions, etc. ...

> * The libtool/autoconf/automake dependency thing is a *MAJOR* headache to

> 	* Write "you need libtool v.x, autoconf v.y and automake v.c to
> 	build LibGGI and friends.  Here's where they are" in big neon
> 	letters (metaphorically speaking) somewhere prominent (like degas/

Yes, and we should put the packages on our FTP. Someone send me pointers
to painlessly installing and newest versions, and I'll put it up there.

> 	* Somehow, we need to check for those version dependencies in
> 	autogen.sh and fail the config/build process cleanly if the
> 	required tool versions are not installed.  Currently the config
> 	process fails with uninformative and confusing error messages
> 	(usually from an old libtool), which are no help unless you
> 	already know what's going on.  This seems to be causing a lot
> 	of unnecessary mails to the mailing list, and it gave *me* a lot
> 	of stress too.  Before my irritation fades, I'd like to stress
> 	how much of a turn-off it is to potential developers to fight
> 	with a balky config/build system for hours.

Yes. We should do both of that.

Marcus - you have the best knowledge of this stuff - could you add the
checks to autogen and send me pointers ? I'll then take care for our ftp
site.

A somewhat "portable" with respect to output formatting way of querying
automake and autoconf version seems to be:

automake --version | head -1 | sed -e "s/.* //"
autoconf --version | head -1 | sed -e "s/.* //"

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =