Pxes structure

Since version 0.5 I've been using Pxes and needed quite a few hacks to get things
"the clients" way.
I want to start a discussion on the pros and cons of the structure Pxes has...

build structure
---------------
[ROOT]
/ scripts
  - pxesconfig
  - check_os
  - pxesbuild  
/ stock
  - arch 
		- kernel
		- modules
  - core
		- pxesconfig.bla	options and questions for pxesconfig.
		- pxesbuild.bla	script needed to build this module
		- files		these files are copied into the ramdisk
  - plugin_x 
		- pxesconfig.bla	options and questions for pxesconfig.
		- pxesbuild.bla	script needed to build this module
		- files		these files are copied into the ramdisk
			\ /etc/pxes.d/plugin_x	configure script (on client)	
			  /etc/config.d/plugin_x settings	
/tools	toolsdir

*note bla is just an imaginairy extention name...

check_os
--------
check if build enviroment is ok.

pxesconfig
----------
Parse the core and plugin directories for pxesconfig files.
Set extra options.
Check for dependencies.
Create the pxes.cfg
In this way other configuration engines can be made without breaking the build engine.

pxesbuild
---------
Use the pxes.cfg and create the ramdisk(s)
This should use as less uncommon OS parts as possible.

pxes image
----------
in /etc/init.d the rcS is a lightweight script which does the core things and does a "rundir" on a pxes.d or something

Why?
----
In this way it might be easier to get it structured and extended.
Otherwise the scripts get larger and larger.



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8