Given that the NRT library is designed to promote code modularization and reuse, we need to build a packaging and build system to help our users build and share their code. We should try to get a prototype up and running ASAP so that we can get our hands dirty writing user code like a real user.
For now, this page will just be a scratchpad of ideas for the system.
The interesting part about NRT is that all modules are compiled as shared libraries and are linked together dynamically by a central application at runtime. When these modules share message definitions (as they should, if the system is going to do anything) then all binaries need to be up to date, lest two modules with different definitions of the same message try to communicate.
This becomes more complex with distributed blackboards! Two computers can try to communicate even if they have totally different compilers and architectures.
First and foremost, we should not try to support communication between heterogeneous platforms. Our main focus is efficiency and usability, and I think supporting data marshalling will destroy both across the board.
The build system should contain all runnable modules within a single file system hierarchy.
As a first stab at synchronization, we can compute an MD5 of the entire source tree and store that along with the module binary. That way, we can refuse to run two modules with different source tree MD5s together.
If this becomes cumbersome in the future we can compute an MD5 of every file in the tree and to dependency tracking to make sure only depended on files are synchronized.
We could also consider giving message definition files a special suffix, e.g.
MyMessages.MSG
or something. That way, we can easily search for just those includes.
We could also just search all include files and find those that include the special message registration macro.
etc.. etc.. We should just try the simplest for now and see if it breaks.
packagingsystem.txt · Last modified: 2010/12/27 10:47 by rand