Re: [ccmtools-devel] more environment stuff

[Teiniker E. <ego...@tu...>]

Hey Leif!

Quoting Leif Johnson <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 !

I used the Christmas days to set up my own home network (xDSL, WLan and
Ethernet). Hey, it's fun to use high speed internet access ;-)


> 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.

I agree with you that separating environment libs from the ccmtools is the
better approach (yes to both advantage 1 and 2).

About the disadvantages, I think that first installing the environment libs and
then building the CCM-Tools is no problem. Until now, we have to call the
install-environment scripts too.

For testing, why do we need to install the environment libs again (and not using
the existing installation)?
Especially the remote environment (that contains the ORB) is not that flexible.

Conclusion: Let us separate the environment lib source code from the CCM-Tools
source code!


> Another question about the environment files : Do we really need to have
> all those separate directories for holding the source files ? Why not
> put all the files in one directory, since they'll be compiled and
> installed together ?

I think it is more clear to separate the source files in directories which
reflect the source code's namespace structure and there is just one Confix call
needed to build and install this stuff.
But, if you really want to change this - why not ;-)

:-) Egon