Re: [ccmtools-devel] more environment stuff

[Joerg F. <jf...@sa...>]

>>>>> "Leif" == Leif Johnson <le...@am...> writes:

I'm catching up a little late since I tried to separate fun and work
over my holidays. (I noticed that these are inseparable however.) I'll
try to comment as we go, so excuse me for commenting on something that
was already commented to death.

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

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

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

This appears to be quite a bit of work, but it's a good idea. You'd
need a lot of conditionals (both automake and C-macro), and testing
all combinations is exponential.

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

Good idea, much less work :-)

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

Agreed, this is a disadvantage. Libtool's library versioning scheme
provides a solution to the problem, it's just that developers have to
take a lot more care. (The macros in WX/Utils/linkassert.h serve the
same purpose, but require equal care.)

But, on the other hand, even with local environment libraries you have
to make sure the user installs them after he got an update, or else he
will run into exactly the same situation.

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

Unfortunately there is no such repository overloading feature. However
I guess this is only necessary when two developers are working on the
same package, on the same machine, that depends on another package. To
share the same installation of that other package, they would share
one repository, and "overload" that one with their own. We need this
feature anyway as it is common practice here to work on the same
machine which uses to be a big one.

You can always install both packages into one
location/repository/prefix, I guess this is what you mean by dealing
with the problem.

Joerg