From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : GGI mailing list <ggi-develop@eskimo.com>
  Date: Sat, 6 Feb 1999 01:11:30 -0800 (PST)

I have seen the stars... at Creative!

	As my first week at Creative draws to a close, I have finally got
my development box configured and have LibGGI up and running.  Boy, Samba
2.0 is a real pain to set up... anyway, here's a list of some points that
I thought of over the course of this week that I think need dealing with: 

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

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

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

* The libtool/autoconf/automake dependency thing is a *MAJOR* headache to
get working properly if you don't already know what to do.  Every single
developer is forced to go through that, since so many of the tool version
dependencies are new and are not available from the standard places on the
net.  I suggest two things be done to help remedy this situation:

	* 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/
	README or degas/lib/README) within the CVS tree.  People should not
	be _required_ to hunt this vital info down on the website or ML
	archives in order to be able to build anything.  It should be
	stuck right in people's faces at the top of all the READMEs. 

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

I don't mean to imply that the new libtool/autoconf/automake system is
bad.  In fact, I advocated such a thing a while back and am glad to see it
being used.  However, it does add quite a bit of complexity and potential
for problems if it isn't all wrapped back together into a simple make
system and documented well.  IMHO, that is not the case currently.  Enough
said.  I'm happy to help work to improve this any way I can.

* LibGGI3D.  I'm absolutely slammed with work, so I don't have time to
spend 40+ minutes carefully crafting replies to the LibGGI3D thread
anymore.  Sorry guys, I realize that there are still people who haven't
"got it" yet as well as some remaining design issues to be worked out but 
I just don't have the time.  However:

	* Other people are allowed to play with the current LibGGI3D sources
	as much as they would like to, withing reasonable limits (check with
	me before committing anything big, don't wipe the repository |->,
	etc).  I have seen a lot of good ideas for LibGGI3D over the past week
	and several people have mentioned that we seem to be getting to the
	"shut up and code" stage.

	* I am considering using LibGGI3D to encapsulate the kernel drivers
	I will be writing, and wrapping them in a LibGGI3D Mesa target.  After
	all, if all the smack I've been talking about LibGGI3D is actually
	true (|->), this would be the logical way to do things IMHO.  I will
	be in the .h stage of driver coding for a little while longer, so this
	decision has a chance to be thought over by GGI and Creative, so I'm
	soliciting feedback now.

* It is Creative policy not to discuss products while they are "in the
pipeline".  The result of this is that I can't discuss which drivers for
which chipsets will be released when, and what I am working on at any
given time (other than 'normal' GGI stuff).  Sorry about that, but that is
the way it has to be.  Do not mail me, my boss or anyone else at Creative
asking for any such info.  We cannot provide it.  I will do my best to see
to it that no work duplication problems arise because of this.  If any
disclosure of "sensitive" (NDA or otherwise) info needs to be made to GGI
coders or any other third parties that may for whetever reason need to be
brought into the loop, that will be handled on a case-by-case and
need-to-know basis.  I'll probably actually be somewhat silent on KGI 
driver issues for a few months on the list.

* Steffen, I didn't get to download and look at the new KGI sources but I 
will next week when I start coding.  Sorry about lagging like that but 
this week was nuts.  I need to familiarize myself with James and 
Fabrice's fbcon patches too.

* Creative is a great place to work.  My cubicle is much larger than at 
my last job |->.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed