Re: division in sub projects (or not ?)

Peter Soetens wrote :
| I'm trying to fit some of my written source code to a good CVS directory 
| structure.  Here at the KULeuven, we think about using sub projects
| under the "Orocos root directory".  Thus each sub project has its own
| src/ include/ doc/ directory, namespaces, etc...

That's also what we do at laas for our src tree.
However, we also use a directory tree for installed components.
I think the src trees should remain independant (thus the structuring of
them is only a matter of cosmetic effets -- not that it's not important
:)

If packages are to refer to each other, I think they should do this
through the {\em installed} hierarchy (and thus through common directories
"doc", "include", etc.). Much like the BSDs' packages/ports.
If you do so, you can for instance work on a partial checkout of the
repository in your home directory, or install two different trees easily.

We also consider using 'configure' scripts for all packages/components,
which would ease a lot compilation/installation processes.


| For "inter-component" communication / linking, we will use an "Orocos
| Wrapper Interface" (ORWIN :-) )  If you want to use a particular system
| call or a  method of another component, you'll have to write a wrapper
| from ORWIN to your Operating System, Module or Component.

We are currently working on a strong decoupling between 'functionalities'
and the 'underlying system' (if you can wait a few hours I should be able
to release a document which would explain further this idea).

'underlying system' comprises all communication functions. I think we
should be able to use several such systems, which would not necessarily
use the same interface. I'm not so sure that  wrappers can do
everything. And furthermore this often adds an overhead which might not
be desirable all the time.

Besides this, ORWIN sounds great :)


| The selection of appropriate wrapper /module / component should be done by a 
| "Configuration Agent" whose sole purpose is to combine hot spots with frozen 
| spots and thus complete the framework (see glossary 
| http://www.orocos.org/glossary.html ).  

Do you think of an 'interface' that would lauch the necessary things in
the right order, or is it something else ?