[ccmtools-devel] more environment stuff

[Leif J. <le...@am...>]

Hi Egon and company !

I'm back in San Francisco after spending Christmas up in Washington
visiting my mom. It's nice to be back and on the internet !

Over vacation I was thinking more about the CCM Tools environment files.
I came up with an idea(tm) : From a Unix perspective (small tools that
perform one task), the CCM Tools shouldn't even include environment
files. We ought to move all these environment files out of the ccmtools
source tree entirely. I started to move them into a different directory,
which I thought we could distribute separately, and include as a
separate CVS module ("cvs checkout environment", perhaps ?). But then I
realized the C++ tests in `make check' would fail since they require the
environment to be installed locally in that tree. Hmm ...

So, what do you think ? It seems that component developers should have
these environment libraries installed before they even install the CCM
Tools. By removing the environment files entirely from the ccmtools
source tree, there are two advantages and two disadvantages that I can
see.

Advantage 1 : Configurability. If the CCM Tools can expect to find
environment libraries already installed on a developer's system, we
could check for those libraries at configure time and selectively
enable/disable some of the generators based on which libraries are
present on the developer's system. For example, the Python wrapper
generator is going to require a small environment library (quite similar
to that of the remote C++ environment) ; we could check for this at
configure time and disable the Python wrapper generator if the library
is not found. Same idea for the remote generator ; we could even try to
detect several different ORBs in the ./configure file, and change the
generators appropriately somehow. This might even be a good solution for
the multi-orb selection problem.

Advantage 2 : Separation of interface and implementation. If the CCM
Tools do not include the implementation code for their libraries
directly, this allows for multiple implementation of those libraries,
provided the interface (API) is well defined. I am thinking specifically
of the CCM_Utils library, which is part of the in-house WX library at
Salomon (is that right ?). If the CCM Tools only care that the library
is installed and available, then we leave it up to the developer to
provide a library implementation that's appropriate for their situation.
This would be a nice way to allow the WX libraries to override the
default CCM Tools implementation.

In addition, if we moved all the environment files to a separate CVS
module, we could remove all the ccmtools-c++-environment scripts and
suchlike. Compiling, installing, and debugging the environment libraries
would be an entirely separate task from working on the CCM Tools. We
could then concentrate on code generation without having to worry about
who provides those external function implementations.

This came to me, actually, when I was thinking that a GObject generator
wouldn't need any external environment files, since they are already
provided in the GObject libraries that GNOME and GTK (and lots of other
projects) rely on. I think the C++ component environment libraries
should be provided in the same way, separate from the CCM Tools
generators. But, onward to the disadvantages.

Disadvantage 1 : More interdependencies. If the CCM Tools rely on
external libraries, inconsistencies can appear. Especially at this point
in development, when the API/ABI (application binary interface, i.e. the
size/composition of classes and structs) for environment libraries is
not stable, we would start to run into component compilation errors
related to version differences in the libraries.

Disadvantage 2 : Testing and Confix. If we move the environment
libraries out of the CCM Tools, then `make check' will fail as it is
now. If the environment libraries are external to the CCM Tools, then
Confix would need to support multiple repositories (does it now ?) to be
able to find the external C++ component libraries as well as using the
internal ones that the test components create. Both of these aspects are
nonnegligible, but I think we can deal with them.

Sorry for the long email, but it's an idea to consider. Let me know what
you think, and we can work out something. Cheers !

leif

-- 
Leif Morgan Johnson : http://ambient.2y.net/leif/