Re: [ccmtools-devel] integration of our python binding

[Egon T. <ego...@gm...>]

Hey Darrell,

> (1) we do not want to use confix; we'd like to have an alternative
> build option for C++ [in particular, we've been using Ant to build
> the C++ portion of the CCMTOOLS distribution, i.e. cpp-environment
> and wx, and Python's build system (e.g. via a setup.py file) build
> everything that gets generated]. While we are not wedded to Ant, we
> don't want to use confix (though this is based on our experience with
> it which is now a few years old). Are you open to introducing another
> C++ build option?

Yes, I think we shoud implement an option for include statement generation.
Actually, I will refactor the C++ generators (like I did for the IDL
generators) during the next few months. So, there is some flexibility
from my side.

> (2) We've introduced another layer below the *_impl.cc/h files which
> provides boiler plate for implementing the components in terms of
> standard and STL types (no CORBA, no CCMTOOLS, etc.). In this mode,
> the *_impl.cc/h files are used to provide wrappers to do any extra
> conversion that may be required. These wrappers are filled in with
> info from XML files. For example, one thing that these wrappers do is
> convert exceptions from the native library into CCMException. Our
> goal here is that the layer (we've called *_cmpt.cc/h) can serve as a
> componentized stdc++ interface to our package, and it also provides a
> clean dividing line between generated code (and the generation
> aparatus) and the hand-coded business logic. Is this something you're
> open to adding as an option (in our version, it is switched on with
> "--coda=<setup-xml-file>")?

OK.

> (3) Our "any" processing seems different from what you added. In
> particular, we needed to go from a Python dictionary to a
> std::map<std::string,casac::variant>. My impression is that your
> implementation only handles structs, and to handle more complex
> things more information is required than can easily be expressed in a
> keyword/value file. We setup these "any" conversions with an XML file
> that lists the to/from conversion functions that are used at each
> stage, i.e. in our case python or "coda" (our independence layer).
> I'll attach a snippet below.

Hmm, I will analyze your example!

> (4) I guess I need to get a new version of WX to be able to build the
> current version of CCMTOOLS.

Yes, you can download this new package (wx-utils-3.1.0) from the Confix hompage:
http://sourceforge.net/project/showfiles.php?group_id=68975

> I hope we haven't diverged too far for us to merge back into the
> mainstream. I tried to make changes in a way that was consistent, but
> in just listing these, I see that there's been a fair bit of
> modification. I guess here's what I would propose we do:
>
> (a) I'll make our version of CCMTOOLS available via anonymous
> subversion so you can get the source and look it over if you're
> inclined to do so.

Yes, that's a good idea!

> (b) we have Redhat RPMs available, and I could build them for SuSE,
> Mandrake, or Fedora if you would like to try it out.
Currently, I run gentoo on my box, so...

> (c) I'll get a version of WX (when someone lets me know where to find
> it), and see if I can, build things sans confix.

Visit the confix.sf.net hompage - even to download the wx-utils-3.1.0
package ;-)

:-) Egon