ccmtools-devel

[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/

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

Re: [ccmtools-devel] more environment stuff

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

Hi again -

On Sat, 2004-01-03 at 10:17, Teiniker Egon wrote:
> 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 ;-)

Nice ! Welcome back from the stone age. :)

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

Yes, excellent. I'm working on updating this as I write this email.
Unfortunately it's quite cold here, and my hard drive is being a bit
sluggish. :-/

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

Yes, I meant that to run the _check_* tests, Confix will have to link
those tests with not only the site-installed environment libraries
(which might be installed under something like /usr or /usr/local), but
also the component libraries that are created in the
test/CppGenerator/sandbox/install/ directory.

Still, I think this problem is manageable. Having external environment
libraries might free us from a lot of painful checking for ORBs and
Python development files.

> > 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 ;-)

No, especially now since we'll be providing these files in a separate
CVS module, it would be a bit cleaner to have the directories. I also
agree with you that it's more helpful to have the namespaces as
directories.

So I'll get these environment files into a CVS module called
`environment'. It shouldn't be a problem at all.

leif

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