[omniORB] Implementation Repository
James Waller
jameswaller@coralwave.com
Thu Mar 6 15:52:02 2003
First, apologies for the long post.
The locations of header files is something I've thought about before,
but at the time I decided against moving them. The reason was that I
thought the include/ directory should be kept for header files that were
to be included by external programs. I wanted to keep the internal
header files separate (such that they wouldn't form part of the
installed package), but then again it's possible that other programs
would like to use header files currently inside the common/ directory.
The imradmin program requires some of them, for example.
A server-side python layer should just need to replicate the
ServerProxyPOA class in the ServerProxyPOA.h header file using python
code, probably consisting of no more than a single file. No C++ code
should be necessary. Everything else would be done as normal through the
omniImR::Repository interface.
The code in common/ is built into a static library at present, so a
shared library will be easy. The name of the library (libcommon.a) will
need to be changed - originally I was not going to make this library an
installable component, you see. libomniImR.so sounds good enough.
I think the revised directory structure could look like this:
config/ Autoconf macro files
doc/ User documentation
src/
common/ Source files for omniImR support library
daemon/ omniImR Daemon source files
imradmin/ imradmin source files
examples/ Stuff originally in test/
EchoClient/
EchoServer/
PREchoServer/
include/
common/ Header files from omniImR support library
daemon/ omniImR Daemon's internal header files
idl/
man/ Manpages for omniimr and imradmin
The sample config file would be placed at the top level. This is closer
to the omniORB package's structure. What do you think?
I will post another tarball soon. I am also placing doxygen comments in
all the classes, so we will have documentation of the internals. There
will also be manpages for the omniimr and imradmin programs.
Cheers,
James
Thomas Lockhart wrote:
> Some additional comments on directory structure and build environment:
>
> o autoconf (for the platforms which support it) can be used for this
> package. The config/ directory would conventionally contain autoconf
> macro files, so perhaps the omniImR.conf file can live somewhere else?
>
> o As autoconf is integrated, the package would be configurable to look
> for an existing omniORB installation, just as is currently done with
> omniORBpy. autoconf supports having separate but cooperating configure
> scripts in child directories. So we can put in autoconf support in the
> standalone tarball, and carry it forward if omniImR is moved into the
> omniORB tree later on.
>
> o common/, daemon/, and imradmin/ contain both header files and cc
> files. There is also an include/ directory which contains only a single
> header file. Should the includes be consolidated into the include/
> directory? Especially if there may be other products (e.g. a server-side
> python layer) which need to see some of the header files to be built.
>
> o If the "common" code is not yet built into a shared library, we will
> want to move toward that. What would the library be called? Something
> like "libomniImR.so"? Perhaps common/ could become src/lib/ (or ??) in
> this tree? And the shared library could be built into lib/ ?
>
Cheers,
James