From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : GGI mailing list <ggi-develop@eskimo.com>
  Date: Wed, 8 Jul 1998 22:00:13 -0700 (PDT)

Degas cleanups

NOTE:  I am cc:ing this to Andy and Steffen to make sure they see it,
becuase this stuf it very important and affects all of us. 

	We have three main subsections of GGI in degas/ at present: KGI
(kgicon/), LibGGI and friends (lib/) and The GGI Console (os/, soon to be
console/).  These are three nominally independent packages, each of which
can be used without the others or in any combination with the others. 
Soon we will have a fourth, Steffen's KII.  However, the current directory
structure and Makefile system are not cleanly separated and the whole
system needs to be more modularized and self-consistent.  

	I am discovering all sorts of things that need work as I try to
get kgicon properly integrated into Degas, and I figure that we might as
well straighten this whole mess out once and for all (yeah right |->)
while we are rearranging things anyway.  Below I have outlined the major
issues as I see them, together with my preferred solutions.  Please,
everyone, look this over and add your two cents.  Yes, I know it is a PITA
to change directory structures in CVS and that is makes it impossible to
use CVS' revisioning to go back to the old state, but I do not think we
can get away from it.

====================


Issue #1: Overall directory structure.  I propose the following:
=========

degas/config
degas/config/rules
degas/config/scripts

	Subsection-independent rules and scripts, same as it is now.

---

degas/doc
degas/doc/txt
degas/doc/html
degas/doc/sgml
degas/doc/sgml/libggi
degas/doc/sgml/libggi/libggi2d
degas/doc/sgml/libggi/libgwt
degas/log/sgml/libgii

	Mostly as it is right now, but since libggi2d, libgwt, and other 
LibGGI extensions are part of LibGGI, they should go in as subdirectories 
of doc/*/libggi.  Also the .txt files are currently in doc/ - IMHO, they 
are just another format and should go in their own directory as well.

---

degas/console
degas/console/include
degas/console/os/linux
degas/console/os/patches/linux

	Allows for GGI Console being used with other OSes besides Linux 
at some point.  Is this necessary?  Will this ever happen?  It is 
happening with KGI, that is why I ask.

---

degas/console/drivers
degas/console/drivers/include
degas/console/drivers/joystick
degas/console/drivers/mouse

	The most uncertain one.  How does KII fit into all this? 
Presumably KII will take over the responsibility of handling input drivers
and GGI Console would talk to it the same way it will talk to fbcon/kgicon
- through an abstract interface.  The question is, should we make 
preparations for KII in the tree, or leave the drivers in GGI Console's 
domain where they are now?  Steffen?  Jason?  Talk to me, guys.  Anyway, 
_if_ KII was put into Degas, I would structure it like this:

	degas/kii
	degas/kii/include
	degas/kii/os/linux
	degas/kii/os/patches/linux
	degas/kii/drivers
	degas/kii/drivers/include
	degas/kii/drivers/joystick
	degas/kii/drivers/mouse

---

degas/kgi
degas/kgi/include
degas/kgi/os/linux
degas/kgi/os/patches/linux
degas/kgi/drivers
degas/kgi/drivers/include

	Yes, I know I put kgicon in degas/kgicon.  I have been regretting
it ever since, but I did not want to overwrite the existing kgi/ and
include/kgi directories and I knew that we'd be having to move lots of
directories around eventually anyway.  kgicon is really just the KGI-fbcon
bridge, and now that people are porting KGI to other OSes (Roadrunner,
Dolphin, FreeBSD) it is not really correct to call all of KGI "kgicon".

---

degas/lib
degas/lib/libggi
degas/lib/libggi/include
degas/lib/libggi/extensions
degas/lib/libggi/extensions/libggi2d
degas/lib/svgalib

	Mostly OK right now, except for deciding where libggi2d should 
go.  IMHO it is a LibGGI extension (and hence part of LibGGI) and so the 
above directory structure would be correct.  However, it is currently 
also present in degs/lib/libggi2d.  We need to resolve this.

---

	Note that there is no top-level degas/include directory.  This is 
sensible, IMHO - there are no shared includes anymore (and if there are 
this is (also IMHO) bad practice and should be cleaned up), so no shared 
include directory should be present.


====================

Issue #2: Makefiles and config system
=========

	The current Makefiles are quite a mess in places.  There is still 
stuff left over from Dali and lots of new stuff that needs to be added to 
reflect the changed directory structure above:

* There are two (three with KII) separate set of includes that can be
linked into linux/include: those for KGI and those for GGI Console. 
Therefore, separate check_link_* make targets are needed. 

* There are also two or three separate sets of kernel patches.  Same
story. 

* The top-level Makefile's check_dev and clean_dev targets are still using
the old /dev/graph setup.  They need to be updated to create the correct
files for GGI Console (kgicon uses /dev/fb which can be assumed(?) to
already be present).  Again, if KII is to be included with Degas it needs 
this too.

	All of the above are currently done in the top-level Makefile. 
This is bad, IMHO - it bloats the top-level Makefile and make it much
harder for new subsections to be added to GGI cleanly.  Same goes for
sub-subsections (KGI driver subsections like chipsets, KII/GGI Console
input device categories like mice/joysticks, etc), sub-sub-subsections,
etc.  Adding or removing a subsection category anywhere in the tree
involves way too much needless pain right now.

	I therefore propose that the above three installation steps be
moved to their respective subsections' Makefiles and integrated with the
rest of those subsections' install options.  The top-level Makefile of any
class of subsections and its associated config system should only be a
convenient way to group config and install/uninstall options (and READMEs)
for whatever subsections are present - it should not be doing
subsection-specific tasks itself. 

	Finally, to make the above really modular, the use of hardcoded
dialog options should be deprecated in favor of a universal, generic
configure menu script to be placed in degas/scripts and a text-based
config option database system somewhat similar to Linux's Config.in files. 
Again, the current .configure system makes it quite painful to add/delete
options and subsections.  This should be possible by simply adding a new
line to a .config-options (or something similar) file and adding/deleting
the appropriate directory.

====================
====================

	The new directory structure and Makefile system described above
above is not nearly as much work as it looks like at first glance, and the
modularity, flexibility and cleanliness it would bring to Degas would be
of immeasurable value.  A lot of it involves cleanups that need to be done
anyway - I just think that we might as well shampoo the carpets and wax 
the floors in addition to vacuuming and dusting |->.

Jon

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