
If you have looked at the way treeps is configured your probably
wondering why I do it the way I do. Well that's a good question
and I have put quite a bit of thought into it. In fact it's an issue 
I have been struggling with for a many years.

First I use the term "localizing" instead of configuring. This
borrows from the other use of localization that I know,
i.e. the routines which adapt to a users/hosts local environment.
While the localizing libraries handle languages, time formatting,
currency symbols etc, these localizing scripts handle things such as

	Graphics Toolkit used
	Toolkit version - to determine what features are available
	Library Locations
	Include file location
	Determining if optional packages are available 
	Screen Res, colour depth
	Window Manager Used
	Desktop used
	What kind of info is in /proc
	...

My goals with this are to delay localization decisions as long
as possible, thus providing the greatest degree of portability
and flexibility.

Why not use another mechanism or a combination of mechanisms?

Well I know of at least a couple of different ways of doing program
configuration, i.e. Imakefiles and the GNU configure suite.
Both of these are very powerful mechanisms and while I don't
claim to fully understand either of them, they don't appear
to fit my needs. What! you say? Well here is my rational:

   First Imakefiles only handle build time config. I need
   something that handles coniguration at build time,
   install time and run time. Imakefile can do install
   time config only if they exist at install time, which
   they don't when I create binary distributions.

   The GNU configure mechanism also has this constraint,
   but could be contorted to produce install time configs.
   The other problem I have with the GNU config, is that
   I find it very difficult to understand. It's based
   on m4 which makes it hard to comprehend and debug(well for
   me at least, and I have programed in lisp and written nroff
   macro's). I tried three different times with it before becoming
   totaly frustrated. Perhaps it's just me, but I find shell
   scripts much easier to work with. 

Don't get me wrong, I think both of these mechanism are very powerful
and I am in no way saying that what I'm doing can do what they do.
It would take years of work to get this mechanism to the same place
these tools are already at. My scope is highly restricted so affords
me the luxury of doing it the way I do.


Anyhow, after much internal debate I decided to roll my own.
It's shell script based and it uses a form of inheritance.
The configuration mechanism, i.e.localization, is
run at build time to create:

	Program defaults - i.e. program #defines  ...
	Resource defaults -  Some X resource parameters
	Build parameters - i.e Makefile variables


At install time the localization process

	Adjusts the X resource file for color depth, screen size, ...

And at run time the localization mechanism will allow for tweaking of the
security model as well as determining which auxilliary programs to run.
There is also much more run time config planned for the future. In fact
it's one of my goals to make the program as run time configurable as
is possible.



Each of these localization steps share some common scripts,
programs and techniques. If you look in the scripts directory
you notice it's at the top of a directory hierarchy. This hierarchy
is composed of a tree consisting of:

	generic - scripts which run across all platforms/versions/...

	{Operating System Name} = uname -s

	   {OS release} = uname -r

	 {Machine Arch} = uname -m

	 Local
	        {Machine Name} = uname -n

The {} items are members of a sparse tree, i.e. the nodes of this tree
are only instantiated if there are scripts resident in them. The
reason for this is to provide a kind of inheritence mechanism. When
major scripts are run, the first thing they do is alter the path.
The directories are pushed on the path in the following order

	generic
	{Operating System Name}
	{OS release}
	{Machine Arch}
	Local
	{Machine Name}

The nodes towards the bottom of the tree will come first in the path.
Thus if a new release of an OS requires a new script to operate on
just that release, its put in {Operating System Name}/{OS release}.
Then the PATH variable will find it first and it then overrides
the same script that would be in {Operating System Name}.
Likewise for architecture and machine specific scripts.

The Local directory allows one to override scripts on the local
machine and can be used to set "local" policy decisions for a
local distribution. These local "decisions" can be overriden by
on a machine by machine basis. Makes sense if you think about it
for a while.


Most scripts are generic, and thats on purpose. Any script that needs
to be more specific should override the generic script. A common one
is

	getMotifX11SupportLibs

which returns the support libs that are needed by X11 and Motif.
These libs appear to be platform specific, and sometimes even
version specific. Well I can't figure out any kind of logic that
can be used to determine what they should be so they are enumerated.

Values that can be calculated, determined or probed are done so by generic
scripts and or programs. The sources for any executable probes are in

	scripts/localize/probes.



Definitions: 

	Localization Vector(LV) - The ordered combination of 
	variables that affect the configuration. This typically includes,
	generic, {OS}, {OS release}, ...

	Localization Vector Tree - The sparse tree that encompasses the
				   total extent of known build variables.



Note that the above examples do not define all known variables, in fact
there are many others. For example a specific OS release for an
architecture may have different executable formats (elf vs a.out). 
Such additional variables can be handled by extending the LV. This can
be done by making the setPath mechanism recursive. In other words after
setting the "standard" localization path, it then calls setPath again
invoking any setPaths in the LV. This would allow the LV to be
incrementally extended from within the scope of the LV.

Such variability is more likely with Linux as there are many distributions.


Install Targets
---------------

In release 1.2.1 I added the ability to build and install for different
target locations. This is done with:

	make local
	make personal

These "builds" set the link scripts/Local/Install to point to some
override scripts. These are used BOTH at build time and install time!
A make clobber resets the link.

A "make local" will install into /usr/local
A "make personal" will install into your own tree, $HOME/bin, $HOME/lib ...

The "make personal" build should always install and is useful for testing.
It never installes setuid to root though, so will be limited. The
"make local" may require you to su to an appropriate user if you
do not have permissions to write in /usr/local. Some places
make /usr/local 777, others use group id's, ... A "Usr Local"
install is also not setuid root by default.



Offset Installs
---------------

New in 1.2.1 are offset installs. These are for package builders. The
concept is that one can push all the installed files into a separate
tree so they don' mingle with the actual system files. This
makes it easy to scoop them up in one tarball RPM. I have added options
to Setup, the script called by make install, to support these. They
are

	Setup [-r root_install_path] [-p prefix]

I use them like this:

	./Setup -r /home2/package_builds -p treeps-1.2.1


If you do a root install, all the files, including the desktop
files are installed under:

	/home2/package_builds/treeps-1.2.1

Note: an Install.prefix file is installed along with these files
in the treeps lib directory. You can cd to the lib directory
and do an uninstall from there. The uninstall uses the prefix
file ... If you create a package/tarball from this area and
install directly into another system, i.e. files from


	/home2/package_builds/treeps-1.2.1/tmp  -> /tmp

Then the uninstall will not work unless you remove/modify the
Install.prefixes file.




