Re: [ccmtools-devel] Local and remote tests

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

Hi Egon -

On Tue, 18 Nov 2003, Egon Teiniker wrote:

> I have implemented some _check_*_remote.cc files that test the
> generated remote components. I'm not sure if I should put these files
> into the test/CppGenerator/*/CCM_Test directories or use a separate
> test/CppRemoteGenerator tree - what do you think about that?

I think it depends on our expected use cases for the CCM Tools. If we
expect typical CCM Tools users to generate code only for local C++
components, then we ought to put the C++ remote testing in a separate
tree. I don't think this is right, however.

My feeling is that a typical C++ developer who downloads the CCM Tools
will want to generate code for remote C++ components. If you agree with
this, let's go ahead and put the remote stuff in the test/CppGenerator
tree.

On a related note, I tried to clean out the test/idl directory a bit
yesterday, so quite a few of the IDL files for the CppGenerator tests
are now in test/CppGenerator/<test_name> directories, instead of
test/idl/<test_name>. I haven't updated the test scripts yet but I'll be
working on that today.

My hope is to have a test tree that looks like this :

test
|-- idl
|   `-- fail
|-- IDL3Parser
|-- IDLGenerator
`-- CppGenerator
    |-- supports
    |-- supports_interface
    |-- supports_inheritance
    |   :
    |   :
    |-- facet
    |-- facet_interface
    |   :
    |   :
    |-- owudb
    `-- calculator

... or something like that. You mentioned this when you were out here :
It will be nice to have each CppGenerator test be contained in its own
directory, so each test can actually perform two functions (testing the
generator and providing examples for developers).

The files in the test/idl directory can still be used for vanilla
testing of the IDL parser and generators, but they ought to remain more
or less canonical examples of IDL syntax (mostly for testing the
parser).

> Have you already used the MParameterDef template to generate (adapter)
> code for different types (MPrimitiveDef, MStringDef, MStructDef,
> MAliasDef,...) in your Python generator? I implemented a lot of
> conversion code in the CppRemoteGeneratorImpl.java file, but I think
> there is a better solution...

Hmm, no, I implemented parameter conversion directly in the two-step
templates (MOperationSupports and such). Primitive types require a
simple conversion to Python data-space, and complex types will have to
call a separate conversion function (that we will have to generate).
I'll have a look at the remote code and see if I notice anything.

Also, for the Python wrapper generator, I'm finding out that it might be
easier just to generate wrappers for C++ classes directly. Not only will
we not need to rely on SWIG then (and generate some sort of Confix call
to do that---even if it is a good idea :), but SWIG's support for C++ is
shaky (no namespace or template support, for example). This whole
namespace + C issue is quite complex ...

leif

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