ccmtools-devel — Development discussion and ideas

[ccmtools-devel] ccmtools c++ environment module

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

Hi all -

I've just created a new CVS module containing the C++ environment for
our generated components. I tried to whip together a build system and
some scanty docs (see INSTALL and README), but I haven't tried building
and installing the module yet.

To check out this module, do the following at a prompt :

  $ cvs -d :ext:use...@cv...:/cvsroot/ccmtools co cpp-environment

If I estimate correctly, we'll need to do a few things in the next few
days to make sure this is a smooth transition :

- make sure the environment builds and installs properly. This
  shouldn't be too much hassle, but we'll need to mess around
  with the Makefile in CCM_Remote/RemoteComponents/. Currently,
  it makes a call to ccmtools-idl, which is in the ccmtools
  package. We can't have this circular dependency, so we might
  need to mess around with how we build the skeletons/stubs
  within the cpp-environment module. I think this will end up
  being some sort of Confix build solution.

- add some checks to the ccmtools/configure.ac script that see
  whether the environment is installed, and enable/disable some
  of the generators appropriately. I'll work on this tonight or
  tomorrow.

- modify the ccmtools/test/Cpp*Generator/ scripts so that the
  environment will be loaded properly during testing. As long
  as we can convince Confix to use multiple repositories, this
  is no problem.

That's it. Sorry for the breakage in advance, but yet again this is
making the tools a more solid package (I think :). Cheers !

leif

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

Re: [ccmtools-devel] library renaming

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

Hi Leif!

Quoting Leif Johnson <le...@am...>:

> OK, I'll test it and check in the changes. I think I've already changed
> the remote generator (at least the Java code and the templates), but if
> you test the remote generators, we'll have our bases covered.

OK!
I also have to implement automated remote tests, because refactoring without
automated tests is a pain ;-)

> >    CCM_Test -> test
> Yes, sounds like an excellent idea. Makes things much clearer for the
> component developer / business logic programmer. I'll change this along
> with the above library names.

Excellent!

:-) 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] library renaming

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

Hi hi !

On Sat, 2004-01-03 at 10:31, Teiniker Egon wrote:
> > I've made the following name(space) changes in my local copy of the CCM
> > Tools, in both the environment files and the component templates :
> >
> >   localComponents --> LocalComponents
> >   localTransaction --> LocalTransaction
> >   remoteComponents --> RemoteComponents
> >
> > I know, it's nitpicky, but I thought it was more consistent with our
> > capitalization so far (SmartPtr, CCM_Utils, etc.).
> 
> So, if the tests are running after this refactoring, please check it in.
> I will change the remote generator in that way too.

OK, I'll test it and check in the changes. I think I've already changed
the remote generator (at least the Java code and the templates), but if
you test the remote generators, we'll have our bases covered.

> There is a naming convention that (in my opinion) can also be changed:
>    CCM_Test -> test
> All the generated directories start with CCM_*, while the manually written or
> modified directories should have different names like src and test.

Yes, sounds like an excellent idea. Makes things much clearer for the
component developer / business logic programmer. I'll change this along
with the above library names.

leif

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

Re: [ccmtools-devel] library renaming

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

Hi Leif!

Quoting Leif Johnson <le...@am...>:

> I've made the following name(space) changes in my local copy of the CCM
> Tools, in both the environment files and the component templates :
>
>   localComponents --> LocalComponents
>   localTransaction --> LocalTransaction
>   remoteComponents --> RemoteComponents
>
> I know, it's nitpicky, but I thought it was more consistent with our
> capitalization so far (SmartPtr, CCM_Utils, etc.).
>
> This would break all kinds of compatibility, however, between old
> environments and new components, so I wanted to find out if I should
> abandon these changes or go ahead and check them in. Let me know.
> Cheers !

So, if the tests are running after this refactoring, please check it in.
I will change the remote generator in that way too.

There is a naming convention that (in my opinion) can also be changed:
   CCM_Test -> test
All the generated directories start with CCM_*, while the manually written or
modified directories should have different names like src and test.
If we package a component, we can remove all the CCM_* directories because ther
is no bussiness or test code contained in. Thus, all CCM_* directories can be
completely generated from IDL3 files.
What do you think about that?

:-) Egon

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

[ccmtools-devel] library renaming

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

Hi again -

I've made the following name(space) changes in my local copy of the CCM
Tools, in both the environment files and the component templates :

  localComponents --> LocalComponents
  localTransaction --> LocalTransaction
  remoteComponents --> RemoteComponents

I know, it's nitpicky, but I thought it was more consistent with our
capitalization so far (SmartPtr, CCM_Utils, etc.).

This would break all kinds of compatibility, however, between old
environments and new components, so I wanted to find out if I should
abandon these changes or go ahead and check them in. Let me know.
Cheers !

leif

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

[ccmtools-devel] environment directories

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

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 ?

This would replace the tree :

  CppLocalEnvironment/
  |-- CCM_Utils
  |   |-- CerrDebugWriter.h
  |   |-- Debug.cc
  |   |-- Debug.h
  |   |-- DebugWriter.h
  |   |-- DebugWriterManager.cc
  |   |-- DebugWriterManager.h
  |   |-- LinkAssert.h
  |   |-- Makefile.am
  |   |-- Makefile.py
  |   |-- SmartPointer.cc
  |   `-- SmartPointer.h
  |-- HomeFinder
  |   |-- HomeFinder.cc
  |   |-- HomeFinder.h
  |   |-- Makefile.am
  |   `-- Makefile.py
  |-- LocalComponents
  |   |-- CCM.h
  |   |-- Makefile.am
  |   |-- Makefile.py
  |   `-- dummy.cc
  |-- LocalTransaction
  |   |-- Makefile.am
  |   |-- Makefile.py
  |   |-- UserTransaction.h
  |   `-- dummy.cc
  `-- Makefile.am

with a shorter tree :

  CppLocalEnvironment/
  |-- CCM.h
  |-- CerrDebugWriter.h
  |-- Debug.cc
  |-- Debug.h
  |-- DebugWriter.h
  |-- DebugWriterManager.cc
  |-- DebugWriterManager.h
  |-- HomeFinder.cc
  |-- HomeFinder.h
  |-- LinkAssert.h
  |-- Makefile.am
  |-- Makefile.py
  |-- SmartPointer.cc
  |-- SmartPointer.h
  `-- UserTransaction.h

Thoughts ?

leif

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

[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] Re: [ccmtools-cvs] ccmtools/CppGenerator CppRemoteGeneratorImpl.java,1.35,1.36

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

Hey Leif!

Quoting Leif Johnson <le...@am...>:

> Sorry I keep bothering you about this, but we really need to have
> Makefile.am files in the environment files directories. These
> Makefile.am files are purely ccmtools autotools files ; they have no
> relationship with the Makefile.am files that Confix creates. The
> ccmtools autotools files are responsible only for installing and
> uninstalling the environment source trees. We have to install the source
> trees so that binary-only distributions of the CCM Tools will be able to
> include the source files for creating component environment libraries.
>
> I assume you've been having problems with these files because of an
> unfortunate coincidence : Confix happens to create Makefile.am files
> when you build the component environment libraries locally, inside the
> ccmtools source tree. Since there's not really any way around this, you
> *cannot* build the environments directly in the CCM Tools source tree !
>
> Instead, component developers must use either (a) the *installed*
> environment files source trees, or (b) a copy of the environment source
> trees. Actually, the test/CppGenerator/test-loader.sh script fakes an
> installation of the environment files :
>
>   data_dir=${sandbox_dir}/share/${PACKAGE}
>   :
>   :
>   for f in ${abssrcdir}/*Generator/*Environment ; do
>   ln -s $f ${data_dir} ; done
>
> And then the ccmtools-c++-environment script copies the files to
> /tmp/ccmtools-cpp-environment directory, and calls confix to make and
> install them.
>
> I won't add back the Makefile.am files until you give the ok. But we
> must have these files in there before we do another release, because
> binary distributions will not be able to include the environment source
> trees otherwise.

Yes you are right in every point!
So, please add the Makefile.am files (again) - sorry for these troubles...

:-) Egon

[ccmtools-devel] Re: [ccmtools-cvs] ccmtools/IDLGenerator IDL2GeneratorImpl.java,1.9,1.10

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

Hmm. I removed this code because it was part of the finalize() function
before. I was a bit wary of this but figured the Makefiles that it wrote
were in fact the same as those in the CppRemoteEnvironment ... must not
have been the case.

I still don't want to add back the finalize() method, since it's crufty.

Instead, you could fix this by doing :

    protected void writeOutput(Template template)
        throws IOException
    {
	super.writeOutput(template);

        template = template_manager.getRawTemplate("MakefilePy");
        output = new File(output_dir, "Makefile.py");
        if (template != null && ! output.isFile())
            writeFinalizedFile("","Makefile.py",template.getTemplate());

        template = template_manager.getRawTemplate("MakefileIdl");
        output = new File(output_dir, "Makefile");
        if(template != null && ! output.isFile())
            writeFinalizedFile("", "Makefile", template.getTemplate());
    }

Or, since these templates don't require information from the CCM graph,
we could treat them as environment files and create an IDL environment
concept ...

leif

On Fri, 2003-12-19 at 07:12, tei...@us... wrote:
> + To generate the Makefile.py and Makefile I changed the IDL2 generator.
>   The problem with this solution is that these files are generated with
>   every single IDL file.

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

[ccmtools-devel] Re: [ccmtools-cvs] ccmtools/CppGenerator CppRemoteGeneratorImpl.java,1.35,1.36

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

Hi Egon -

Sorry I keep bothering you about this, but we really need to have
Makefile.am files in the environment files directories. These
Makefile.am files are purely ccmtools autotools files ; they have no
relationship with the Makefile.am files that Confix creates. The
ccmtools autotools files are responsible only for installing and
uninstalling the environment source trees. We have to install the source
trees so that binary-only distributions of the CCM Tools will be able to
include the source files for creating component environment libraries.

I assume you've been having problems with these files because of an
unfortunate coincidence : Confix happens to create Makefile.am files
when you build the component environment libraries locally, inside the
ccmtools source tree. Since there's not really any way around this, you
*cannot* build the environments directly in the CCM Tools source tree !

Instead, component developers must use either (a) the *installed*
environment files source trees, or (b) a copy of the environment source
trees. Actually, the test/CppGenerator/test-loader.sh script fakes an
installation of the environment files :

  data_dir=${sandbox_dir}/share/${PACKAGE}
  :
  :
  for f in ${abssrcdir}/*Generator/*Environment ; do
  ln -s $f ${data_dir} ; done

And then the ccmtools-c++-environment script copies the files to
/tmp/ccmtools-cpp-environment directory, and calls confix to make and
install them.

I won't add back the Makefile.am files until you give the ok. But we
must have these files in there before we do another release, because
binary distributions will not be able to include the environment source
trees otherwise.

leif

On Fri, 2003-12-19 at 07:09, tei...@us... wrote:
> Update of /cvsroot/ccmtools/ccmtools/CppGenerator
> In directory sc8-pr-cvs1:/tmp/cvs-serv28862
> 
> Modified Files:
> 	CppRemoteGeneratorImpl.java 
> Log Message:
> - Removed the Makefile.am files from the Environment directories because
>   these files are created by confix.
> + Refactored the remote generator to handle the new namespace concept.
>   (CppRemoteGenerator/facet and facet_user_types examples are running)

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

[ccmtools-devel] Re: [ccmtools-cvs] ccmtools/CppGenerator Makefile.am,1.9,1.10

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

Hi hi -

I hope these changes I checked in weren't too drastic. You probably
noticed ; I separated the environment/{local|remote} directories into
CppGenerator/Cpp{Local|Remote}Environment, it seemed to make more sense
with the existing directory structure.

On Tue, 2003-12-16 at 04:52, tei...@us... wrote:

> - The environment files should not be built at ccmtools compile-time.
>   Thus I removed these lines from Makefile.py The environment files
>   will be compiled by the component developer using Confix calls.

Right, but the recent Makefile additions don't actually build the
environment files ; they just install the *.cc, *.h, and Makefile.py
files into $prefix/ccmtools/share/Cpp{Local|Remote}Environment/blah as
data ... no compiling involved, just copying. Just like the templates.

The reason for this is that when we distribute binary versions of the
CCM Tools (i.e. .deb or .rpm files) then we'll have to provide these
environment files in some sort of installed location. Normally I'd put
the header files in
$prefix/include/ccmtools/Cpp{Local|Remote}Environment/blah, but with
*.cc files, we can't do that, and Confix is happier with the *.cc and
*.h and Makefile.py files all together. Hence they get installed in
$prefix/ccmtools/share/ for the moment.

I'm going to revert this checkin unless you object ... we have to
install these files as data somewhere, just like the templates. The only
debatable thing is where we install them.

> + To make the ccmtools compile, I added these empty templates to the
>   CppPythonTemplates directory.

Sorry about that ; I have some templates for these on my machine but
haven't checked them in yet. I'll try to do that today. I'll also work
on removing the environment stuff from the generators today ; should
clean up a lot of the code. Yay !

leif

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

[ccmtools-devel] environment

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

Hey Leif!

I have checked out the moved environment directories in CppGenerator/ - well
done, but there was a problem when I tried to build the ccmtools. The problem
was related to the build of these environment files...
In my opinion, the environment files should be compiled by the component
developer after installing the ccmtools.

I also noticed the changes of the namespace stuff - the remote generator does
not work any more ;-)
However, this looks like a good refactoring step, and it's an opportunity for me
to refactor the remote generator's handleNamespace() method.
Namespaces in the remote generator are a little bit tricky because I have to
handle local namespaces, remote namespaces and the generated namespaces from
the IDL stubs that are something in between...

:-) Egon

Re: [ccmtools-devel] python wrapper status

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

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

Leif> Hi Joerg !
Leif> On Fri, 12 Dec 2003, Joerg Faschingbauer wrote:

>> >>>>> "Leif" == Leif Johnson <le...@am...> writes:
>> 
Leif> I'm still hacking on the Python wrapper generator. It's a bit slow
Leif> going, but progress is happening. I think the wrappers will be really
Leif> clean when they're finished ; there is a nice mapping between Python
Leif> objects and the CCM component structure, at least so far. The big issue
Leif> is going to be converting interfaces to Python and back---eech.
>> 
>> I'm not sure if I mentioned this already. In the wx-utils package that
>> you can download from http://sourceforge.net/projects/confix, there is
>> a glue module ext-python that you can use to automatically pull in the
>> Python include path and library.

Leif> My current approach has been to use an EXTERNAL_LIBRARY call in a
Leif> Makefile.py. This, like the Mico issue, has the problem of hard coding a
Leif> version number in the external library call (does the developer have
Leif> python 2.2 or 2.3 headers---or maybe even 1.5 ?). But for the moment it
Leif> will have to do.

Leif> Is there any way we could hack up Confix to accept a list of include
Leif> directories to search for a provided header file ? (Does it do this
Leif> already ?) But even this isn't a great solution, since developers might
Leif> have stuff installed in all sorts of nonstandard locations.

Leif> Ahh, standardization ... how easy and boring things would be.

Yeah, isn't variability great?

The autoconf thing in wx-utils/ext-python module does what you
want. The Python interpreter that is found in your path
(AM_PATH_PYTHON does that) is asked for its install prefix, and the
locations of headers and libraries are deduced from that.

Joerg

Re: [ccmtools-devel] Re: [ccmtools-cvs] ccmtools/environment README,1.1,1.2

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

Hi Leif!

Quoting Leif Johnson <le...@am...>:
> This README file looks great ! I'll try to incorporate this information
> into the tutorial/developer's guide sometime this weekend.

I started work on the tutorial too :-)
There two new chapters called Programming Model and Remote Components.
Unfortunately, these chapters describe not the current state of the art - thus,
I will change some parts of it...

> Do you have any objections to moving the ccmtools/environment/ directory
> to ccmtools/CppGenerator/environment/ ? I guess we could make a separate
> CVS module for these files, but it seems more appropriate for this code
> to go in the ccmtools module directly.

No objections!
The ccmtools/CppGenerator/environment/ directory is a good place for that code.

> Finally, since you're moving them to the environment tree, can we remove
> the environment files from the CppLocalTemplates/ directory ? I hate
> having duplicated code ... and moving environment files to a static
> source tree makes a lot more sense than keeping them in the more dynamic
> code generator template directories. Then we could even remove the
> environment files capabilities from the CCM Tools entirely---this would
> clean up the code generators a bit, which would be nice.

Yes, I think we should remove the environment templates and the environment
files capabilities from the CCM Tools.
Hmm, what's about the test scripts - I think they should use the installed
environment...

> Let me know what you think. I know you're working on this at the moment
> and don't want to create any conflicts with what you're working on.

I guess we are on the right way!

:-) Egon

Re: [ccmtools-devel] python wrapper status

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

Hi Joerg !

On Fri, 12 Dec 2003, Joerg Faschingbauer wrote:

> >>>>> "Leif" == Leif Johnson <le...@am...> writes:
> 
> Leif> I'm still hacking on the Python wrapper generator. It's a bit slow
> Leif> going, but progress is happening. I think the wrappers will be really
> Leif> clean when they're finished ; there is a nice mapping between Python
> Leif> objects and the CCM component structure, at least so far. The big issue
> Leif> is going to be converting interfaces to Python and back---eech.
> 
> I'm not sure if I mentioned this already. In the wx-utils package that
> you can download from http://sourceforge.net/projects/confix, there is
> a glue module ext-python that you can use to automatically pull in the
> Python include path and library.

My current approach has been to use an EXTERNAL_LIBRARY call in a
Makefile.py. This, like the Mico issue, has the problem of hard coding a
version number in the external library call (does the developer have
python 2.2 or 2.3 headers---or maybe even 1.5 ?). But for the moment it
will have to do.

Is there any way we could hack up Confix to accept a list of include
directories to search for a provided header file ? (Does it do this
already ?) But even this isn't a great solution, since developers might
have stuff installed in all sorts of nonstandard locations.

Ahh, standardization ... how easy and boring things would be.

leif

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

[ccmtools-devel] Re: [ccmtools-cvs] ccmtools/environment README,1.1,1.2

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

Hi Egon !

On Thu, 11 Dec 2003, tei...@us... wrote:

> Modified Files:
> 	README 
> Log Message:
> - The ccmtools do not need to link the micoccm2.3.11.so lib (a segmentation fault 
>   can occur because of common global identifiers in CCM.cc)
> + A README file explains the installation of the component environment.  

This README file looks great ! I'll try to incorporate this information
into the tutorial/developer's guide sometime this weekend.

Do you have any objections to moving the ccmtools/environment/ directory
to ccmtools/CppGenerator/environment/ ? I guess we could make a separate
CVS module for these files, but it seems more appropriate for this code
to go in the ccmtools module directly.

Finally, since you're moving them to the environment tree, can we remove
the environment files from the CppLocalTemplates/ directory ? I hate
having duplicated code ... and moving environment files to a static
source tree makes a lot more sense than keeping them in the more dynamic
code generator template directories. Then we could even remove the
environment files capabilities from the CCM Tools entirely---this would
clean up the code generators a bit, which would be nice.

Let me know what you think. I know you're working on this at the moment
and don't want to create any conflicts with what you're working on.

leif

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

[ccmtools-devel] Re: [ccmtools-cvs] ccmtools/CppGenerator/CppLocalTemplates MProvidesDefAdapterDefinition,1.2,1.3 MProvidesDefProvidePrototype,1.2,1.3

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

yes, excellent. thanks for this change.

leif

On Fri, 12 Dec 2003, tei...@us... wrote:

> Update of /cvsroot/ccmtools/ccmtools/CppGenerator/CppLocalTemplates
> In directory sc8-pr-cvs1:/tmp/cvs-serv12746/CppLocalTemplates
> 
> Modified Files:
> 	MProvidesDefAdapterDefinition MProvidesDefProvidePrototype 
> Log Message:
> + The component's provide_<facet-type>() method now returns a 
>   SmartPtr<<facet-type>> instead of SmartPtr<<CCM_facet-type>>.

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

Re: [ccmtools-devel] python wrapper status

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

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

Leif> I'm still hacking on the Python wrapper generator. It's a bit slow
Leif> going, but progress is happening. I think the wrappers will be really
Leif> clean when they're finished ; there is a nice mapping between Python
Leif> objects and the CCM component structure, at least so far. The big issue
Leif> is going to be converting interfaces to Python and back---eech.

I'm not sure if I mentioned this already. In the wx-utils package that
you can download from http://sourceforge.net/projects/confix, there is
a glue module ext-python that you can use to automatically pull in the
Python include path and library.

The module is referred to in section "Using Third Party Libraries"
where there is explained what the glue code does.

Joerg

Re: [ccmtools-devel] ccmtools/environment

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

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

>> The external/mico thing is a major pain in the ass. Google just told
>> me that there is a more sophisticated autoconf piece in the autoconf
>> macro archive
>> (http://www.gnu.org/software/ac-archive/htmldoc/ac_pkg_mico.html). As
>> Confix comes with that archive, it would be fairly easy to integrate
>> it. I'd give it a try over the weekend, if you want. AC_PKG_MICO
>> doesn't know of CCM however, but we're not using that anyway.
>> 
>> Having a confix module for mico would be a good example for how
>> external packages are glued into confix, so it's not a bad idea to put
>> it in the utils package.

Leif> So this is a utils package that's part of Confix, or a Salomon internal
Leif> package ? I'm a bit confused. Also, I'd like to clarify the separation
Leif> between the WX_Utils package and the CCM_Utils package ... which is
Leif> which ?

Ah, sorry. This is a Salomon module, and I suppose you've never seen
it. It's Makefile.py is

EXTERNAL_LIBRARY(
    enabled='no',
    defroot='/usr/local',
    incdir='include',
    libdir='lib',
    lib_bases=['micoccm2.3.10',
               'micocoss2.3.10',
               'mico2.3.10',
               # mico needs dlopen() and friends
               'dl'],
    provide=['CORBA.h'],
    featuremacros=['HAVE_MICO']
    )

It doesn't have any shell code to determine the more detailed
properties of the Mico installation, but rather has the libraries and
their version numbers hardcoded. Pain.

What you need in your remote C++ environment is a way to tell Confix
that it should link in the Mico libraries where needed (that is, when
<CORBA.h> is seen in a source file). Egon was thinking of using the
external/mico module above. My suggestion was to add a module to your
environment instead that has the necessary glue code (using
AC_PKG_MICO) that I posted.

Joerg

[ccmtools-devel] python wrapper status

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

Hi all -

I'm still hacking on the Python wrapper generator. It's a bit slow
going, but progress is happening. I think the wrappers will be really
clean when they're finished ; there is a nice mapping between Python
objects and the CCM component structure, at least so far. The big issue
is going to be converting interfaces to Python and back---eech.

I made a couple of changes to the C++ generators. Notably, the base
CppGenerator class now has a list called base_namespace that can hold
any base namespaces needed by the child classes. For the
CppLocalGeneratorImpl, this list holds [ "CCM_Local" ], for the remote
generators it could hold [ "CCM_Remote" ], and for the
CppPythonGeneratorImpl it holds [ "CCM_Test", "Python", "CCM_Local" ].

These base namespaces are added to the namespace stack when the code
generators start processing a graph, so we (hopefully) don't need as
many hacks in the handleNamespace function (which is kind of a hack
anyway ; that's what you get for having a Python coder design things for
you. :).

leif

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

Re: [ccmtools-devel] ccmtools/environment

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

Hi -

I have to admit I'm a bit lost on this subject.

Here's my understanding. We're trying to provide a way for CCM Tools
users (i.e. component developers) to create the necessary environment
for using any of a number of different CORBA ORBs (Tao, Mico, ORBit,
etc.). We could do this by either providing some sort of complimicated
development script that would generate Confix development files
depending on the name of the ORB the developer wants to link with. Or we
can just provide a directory of the appropriate Confix files, and let
the component developer compile their components with the appropriate
ORB environment files as part of the component source tree. Let me know
if I'm mistaken on this.

On Thu, 04 Dec 2003, Joerg Faschingbauer wrote:

> >>>>> "Egon" == Teiniker Egon <ego...@tu...> writes:
> 
> Egon> Hi all!
> Egon> There is a new ccmtools/environment directory that contains some C++ and IDL
> Egon> files needed for creating environment libraries for components.
> 
> Egon> environment/
> Egon> |-- external
> Egon> |   `-- mico
> Egon> |-- local
> Egon> `-- remote
> Egon>     |-- CCM_Session_Container
> Egon>     `-- remoteComponents
> 
> Egon> We need an external/mico package that tells confix where to find the mico
> Egon> libraries and, for remote components, the CCM_Session_Container and the
> Egon> remoteComponents package.
> 
> Egon> Note that (except for external/mico) the environment packages for local and
> Egon> remote components can be installed using the ccmtools-c++-environment and
> Egon> ccmtools-c++remote-environment scripts. In that case, the source files are
> Egon> created from CppGenerator templates.
> Egon>
> Egon> But, there is a serious drawback using these scripts. Some of the environment
> Egon> sourc code (external/mico, etc.) are also part of the WAMAS-X framework that is
> Egon> the main user of the ccmtools. Thus, we need a flexible way to decide which
> Egon> package to install.

So, if I understand, these new directories are necessary for holding the
Confix Makefiles and other supporting development information to build
CCM Tools components using these different ORBs. Right ? Is the
ccmtools-c++remote-environment script responsible for copying the
appropriate directory to the component source tree ?

> Egon> I think that the ccmtools/environment directory can be a good solution, because
> Egon> it leaves the decision of what packages are needed and what packages are
> Egon> already installed by the component developer. He has to call confix for the
> Egon> needed packages.
> 
> Egon> So, what do you think about this idea?

My only suggestion at this point is a package maintenance one : Because
these environment files are appropriate only for the C++ generator
family, we should move the entire ccmtools/environment/ directory to
ccmtools/CppGenerator/environment/. If you don't have any objections I
can do this tomorrow or the next day.

And are these environment directories to be installed when the CCM Tools
are installed ? Seems like they're analogous to the template
directories, so yes, right ? My suggestion for installation is
$(pkgdatadir)/CppGenerator/environment/.

> The external/mico thing is a major pain in the ass. Google just told
> me that there is a more sophisticated autoconf piece in the autoconf
> macro archive
> (http://www.gnu.org/software/ac-archive/htmldoc/ac_pkg_mico.html). As
> Confix comes with that archive, it would be fairly easy to integrate
> it. I'd give it a try over the weekend, if you want. AC_PKG_MICO
> doesn't know of CCM however, but we're not using that anyway.
>
> Having a confix module for mico would be a good example for how
> external packages are glued into confix, so it's not a bad idea to put
> it in the utils package.

So this is a utils package that's part of Confix, or a Salomon internal
package ? I'm a bit confused. Also, I'd like to clarify the separation
between the WX_Utils package and the CCM_Utils package ... which is
which ?

leif

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

Re: [ccmtools-devel] ccmtools/environment

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

>>>>> "Egon" == Joerg Faschingbauer <jf...@sa...> writes:

Egon> The external/mico thing is a major pain in the ass. Google just told
Egon> me that there is a more sophisticated autoconf piece in the autoconf
Egon> macro archive
Egon> (http://www.gnu.org/software/ac-archive/htmldoc/ac_pkg_mico.html). As
Egon> Confix comes with that archive, it would be fairly easy to integrate
Egon> it. I'd give it a try over the weekend, if you want. AC_PKG_MICO
Egon> doesn't know of CCM however, but we're not using that anyway.

Egon> Having a confix module for mico would be a good example for how
Egon> external packages are glued into confix, so it's not a bad idea to put
Egon> it in the utils package.

Just tried out AC_PKG_MICO. It didn't work right out of the box: m4
said,

configure.in:219: /usr/bin/m4: Bad regular expression `[[[\([[[[]]]]\)]]]': Unmatched ) or \)

Don't know what that means, but after a binary search in
confix/share/confix/ac-m4/autoconf-archive/m4source/ac_pkg_mico.m4 I
applied a bad hack to make it run. If you want to try it out, you'll
have to get the CVS version of confix to get that revision. (I use to
maintain the autoconf archive on a vendor branch.)

The check uses the mico-setup.sh script to determine the build
parameters. If you have mico in a default location (something like
/usr, /usr/local or so), you don't have to specify anything on the
configure commandline. If you haven't, you have to pass the path name
to mico-setup.sh as the "--with-mico=" value; for example,

configure --with-mico=$HOME/mico-2.3.10-gcc-2.95.3/lib/mico-setup.sh

See http://www.gnu.org/software/ac-archive/htmldoc/ac_pkg_mico.html
for details.

So how to tell confix about it?

I refrained from putting it into the utils package, because I don't
want the user to have to specify any configure options if he doesn't
care. (He'd have to say "--without-mico" to compile utils if he has no
mico installation.)

Anyway, it's easy to create a glue module yourself. Just create a
module directory (I suppose the right place is the remote environment)
with a Makefile.py as follows.

# announce that we satisfy any #include <CORBA.h> directive.

PROVIDE_H('CORBA.h')

# place the AC_PKG_MICO invocation in the using package's
# configure.in.

CONFIGURE_IN(lines=['AC_PKG_MICO'],
             id='AC_PKG_MICO',
             order=AC_LIBRARIES)

# AC_PKG_MICO will AC_SUBST the MICO_INCLUDE and MICO_LIB variables;
# place them on the using module's compile and link lines.

EXTERNAL_LIBRARY2(inc='@MICO_INCLUDE@',
                  lib='@MICO_LIB@')


Cheers,
Joerg

Re: [ccmtools-devel] ccmtools/environment

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

>>>>> "Egon" == Teiniker Egon <ego...@tu...> writes:

Egon> Hi all!
Egon> There is a new ccmtools/environment directory that contains some C++ and IDL
Egon> files needed for creating environment libraries for components.

Egon> environment/
Egon> |-- external
Egon> |   `-- mico
Egon> |-- local
Egon> `-- remote
Egon>     |-- CCM_Session_Container
Egon>     `-- remoteComponents

Egon> We need an external/mico package that tells confix where to find the mico
Egon> libraries and, for remote components, the CCM_Session_Container and the
Egon> remoteComponents package.

Egon> Note that (except for external/mico) the environment packages for local and
Egon> remote components can be installed using the ccmtools-c++-environment and
Egon> ccmtools-c++remote-environment scripts. In that case, the source files are
Egon> created from CppGenerator templates.
Egon> But, there is a serious drawback using these scripts. Some of the environment
Egon> sourc code (external/mico, etc.) are also part of the WAMAS-X framework that is
Egon> the main user of the ccmtools. Thus, we need a flexible way to decide which
Egon> package to install.
Egon> I think that the ccmtools/environment directory can be a good solution, because
Egon> it leaves the decision of what packages are needed and what packages are
Egon> already installed by the component developer. He has to call confix for the
Egon> needed packages.

Egon> So, what do you think about this idea?

The external/mico thing is a major pain in the ass. Google just told
me that there is a more sophisticated autoconf piece in the autoconf
macro archive
(http://www.gnu.org/software/ac-archive/htmldoc/ac_pkg_mico.html). As
Confix comes with that archive, it would be fairly easy to integrate
it. I'd give it a try over the weekend, if you want. AC_PKG_MICO
doesn't know of CCM however, but we're not using that anyway.

Having a confix module for mico would be a good example for how
external packages are glued into confix, so it's not a bad idea to put
it in the utils package.

Joerg