[Cook] two questions

[Aryeh M. Friedman]

First keep in mind I am very new to cook (have had it for 2 days but
just now figured out how to customize the whole project cooked recipes
to my project... BTW even though I still a total newbie even for a small
subset of my project it has proven MANY MANY times smarter then make [I
got sick of forgeting what libs needed to be recombiled if I modifed some
deeply nested dependcy in a very low level lib).  I have some questions:

1) My project has a "main" project and a set of "coding tools" as a 
secondary project (all the source code in both projects is unique to
my project) and the cooked process of the "main" project requires that
the tools be present.  How do I tell "recursive" to cook the tools FIRST 
then main project (the two dirs are tools and src respectivally).

2) Preferable I whould like to have one top level Howto.cook that does
not need to call other cooks recursively.  One reason I am not doing this
for .o files I can not figure out how to tell it that C files (.c) ARE NOT
the same as (.cpp) files [something like c_src = [fromto %0%.c %0%.o ...]
and cpp_src = [fromto %0%.cpp %0%.o ...] but neither seems to work the
way I expect them to])

	A) If at all possible I want to make this a "included" file so
	that I can just put a stub Howto.cook in each dir that will just
	cook that dir [using the SAME recipes as the "master" cook does].
	I.e. make it so all recipes are guernteed to work as they whould
	in "real life" except just for a subproject.

3) In the "main" project I DO NOT want one monolithic library for the
entire project I want each "facade" [sorry for the oo jargon... just
think of this as each main module in the lib] to be its own library.
This raises two questions that I can't quite figure out if each dir
in say src/lib is a different library and may or may not depend on other
libaries {and autogenerated include files for each lib} with each library
having a default program cooked to debug it [debug.cpp].  How do I make
sure that libraries are cooked in the right order for example if lib X
uses the linked list class [in the adt lib] then the adt lib needs to
be cooked befor X.

	a) How have cook figure out what libraries need to be compiled
against automatically (i.e. if the Y library uses libraries X and Z I
want it to deduce this fact) [assume that all depencies will be the same
as the "global" includes list for non-system (i.e. autogenerated header
files from the results of cooking depent libraries)... i.e. if we need
to compile against the adt lib there will ALWAYS be a #include <adt.h>
see below for some details on this)

	b) All cooked source files (.c and .cpp) include only a single
file called "includes.h" that then lists all the includes used
by EVERY source file in that dir.  This file contains "system" includes 
(in reality just the header files made by previously cooked libraries)
i.e. one way to deduce if a lib has a uncooked depency is to check
the datastamp of it's header file.

4) The stuff on platform indepence is a little unclear on how to use
it for my project.  In my case I have a common "API" for all platforms
that just creates the right bindings to the proper backend API 
implimentation (i.e. something like socket(2) whould be the DEFAULT API
but if the target platform does not have socket(2) it will swap in
the right backend file [i.e. the "facade" of the API at the API definition
level never changes just what it is bound to on the backend... I know this
is a little hard to explain but I have an class called "platform"
which then in turn makes calls to an other (abstract) class called "OS" then
OS class'es methods are inherited by say the "FreeBSD" (actually Unix,
BSD AND FreeBSD classes) since all the methods in OS are virtual they
just fall through to their concrete versions in what ever concrete OS
layer object can handle them... in order to support say Windows you just
compile it using the Windows hierachy OS classes vs. the UNIX ones [i.e.
plug-in-play swapping of concrete platform methods at compile time]).
The question is if supplied the proper combination of backends to compile
in some hdr file (conf.h) cook can deduce the right platform to build,
1) Is this possible, 2) How do I do it.
	a) When making binary distrubtions I want to only include the
stuff needed for that platform (including the documentation)

5) One functionality my project has is the ability to call an arbitary
function as defined by a string literal... In psedo-code:

	func="foo";

	func(...);	// calls foo(...)

	Note: The literal it self can come from file/database

	Due to not having a single monolithic lib this confuses some
linkers (i.e. they "optimize" out any non-referenced symbols).  This
may not be a cook issue but is there a way of still having some optomizing
(i.e. if some target NEVER calls and or can call foo then foo is optimized
out but it can call it based on say some database field value then it should
not optimize it out)

6) An othre piece of functionality that might confuse cook and maybe
some other parts of the build process is the project has the ability
to load and unload dynamic libs while the programming is running (i.e. hot 
swapable modules) is there any way to compile and toss the right commands 
[assume either via software interupt and/or some OS script] to the OS to 
compile then swap an new module in [the modules them selves can and 
probally will be third party products]).  Is there any way to minimize this 
confusion.

7) The same as item 6 but for databases.  I.e. there are two databases
that we use one is a development the other is a production one [and
these can at run time be hot swapped for 3rd party ones].  How can I make
sure 1) the correct DB is shipped with the product [not the development
one], 2) make it easy for end-users to do the hot swap of databases.

	I appolize for a lot of questions, but as you can see it is a
complex project and cook is the only build tool I was able to find that
"might" be able to handle it.  If not I will have to maybe write some
"glue" programs to make it so cook can do stuff right.

	--Aryeh