Menu
▾
▴
ccmtools-devel — Development discussion and ideas
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(3) |
Jun
(1) |
Jul
|
Aug
(14) |
Sep
(4) |
Oct
(34) |
Nov
(25) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(29) |
Feb
(15) |
Mar
(4) |
Apr
(7) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
(6) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
(5) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
From: Teiniker E. <ego...@tu...> - 2003-12-04 02:48:14
|
Hi all!
There is a new ccmtools/environment directory that contains some C++ and IDL
files needed for creating environment libraries for components.
environment/
|-- external
| `-- mico
|-- local
`-- remote
|-- CCM_Session_Container
`-- remoteComponents
We need an external/mico package that tells confix where to find the mico
libraries and, for remote components, the CCM_Session_Container and the
remoteComponents package.
Note that (except for external/mico) the environment packages for local and
remote components can be installed using the ccmtools-c++-environment and
ccmtools-c++remote-environment scripts. In that case, the source files are
created from CppGenerator templates.
But, there is a serious drawback using these scripts. Some of the environment
sourc code (external/mico, etc.) are also part of the WAMAS-X framework that is
the main user of the ccmtools. Thus, we need a flexible way to decide which
package to install.
I think that the ccmtools/environment directory can be a good solution, because
it leaves the decision of what packages are needed and what packages are
already installed by the component developer. He has to call confix for the
needed packages.
So, what do you think about this idea?
:-) Egon
PS: The WX::Utils (a substitution for the old CCM_Utils) could be distributed in
ccmtools/environment/local too!
|
|
From: Teiniker E. <ego...@tu...> - 2003-12-02 22:20:09
|
Hey Leif! J=F6rg and me are working on the integration of a confix version that can ha= ndle idl files into the ccmtools project. After a XP session today, I think we can do this in the next couple of days.= .. The local generator and the IDL generator are working well - no bugs found w= hile working on remote examples! :-) Egon |
|
From: Teiniker E. <ego...@tu...> - 2003-11-27 17:38:59
|
Hey Leif!
The remote generator can handle IDL modules as shown in the following example:
module world {
module europe {
module austria {
struct Person {
long id;
string name;
};
typedef sequence<long> LongList;
typedef sequence<string> StringList;
typedef sequence<Person> PersonMap;
interface Console {
LongList foo1(in LongList l1, inout LongList l2, out LongList l3);
StringList foo2(in StringList s1, inout StringList s2, out StringList s3);
Person foo3(in Person p1, inout Person p2, out Person p3);
PersonMap foo4(in PersonMap p1, inout PersonMap p2, out PersonMap p3);
};
component Hello
{
provides Console console;
};
home HelloHome manages Hello
{
};
};
};
};
As you can see, the remote components are on their way...
:-) Egon
|
|
From: Teiniker E. <ego...@tu...> - 2003-11-21 15:13:19
|
Hi Leif! I have hacked the current version of the CppRemoteGeneratorImpl that we can generate the remote component logic for the attached example. Note that this is a hack version because the strategy to generate the adapter code within a single method does not cover all use cases we will have. Particular, when using recursive constructs (e.g. sequence of struct that has a sequence as member, etc.). Thus, I have to read the Henning/Vinoski book five times (again) to find a better solution! One possible way could be to generate adapter helper classes for each user-type and use these helper classes in the facet adapter methods - we will see... :-) Egon |
|
From: Teiniker E. <ego...@tu...> - 2003-11-21 08:44:45
|
Hey Leif!
Quoting Leif Johnson <le...@am...>:
> Hi Egon -
>
> I went on a tour de force today and merged the _user_types and
> _basic_types tests together. Since the CCM Tools no longer has they
> `user' or `basic' type distinction, I thought it would be cleaner to
> merge the tests. I'm doing make check right now, will let you know how
> it turns out.
>
> Also, what do you think of merging the _interface tests in with the
> _types tests ? Seems like an interface is just another type, no ?
Yes, that's OK - it will reduce the make check time significantly!
> I also removed some of the basic tests that were already covered by the
> _types tests. I noticed a couple of _check_CCM_Remote_*.cc test files
> getting removed, I'm sorry if I got rid of the tests that you're trying
> to merge in from the remote generator. :-/ We'll get it worked out
> though.
No problem, I will collect the remote tests in the same way - as far as they run
through... ;-)
Hey, the remote generator is able to generate struct adapters now!!!
> I think I'm going to set up a new ccmtools mailing list, ccmtools-cvs,
> which will send us an email whenever people commit something to cvs.
> Would be a nice way to keep track of what everyone's working on.
That would be helpful - in particular for the large developer community in the
future of ccmtools...
;-) Egon
> On Wed, 19 Nov 2003, Egon Teiniker wrote:
> > Quoting Leif Johnson <le...@am...>:
> > > Why don't we create the remote environment when we create the local
> > > environment, and get rid of the ccmtools-c++remote-* scripts ? We can
> > > add a switch to the ccmtools-c++-{environment|generate} scripts to do
> > > the remote environment, components and tests. There's already a switch
> > > in there for the Python wrappers ; it just isn't used at the moment.
> > > Comments ?
> >
> > I think that installing and using the local components is much easier
> > (no CORBA) that handling remote components. Thus, local components can
> > be the gateway drug to CCM ;-) After that the remote stuff is just
> > another step...
> >
> > So I think that we should separate the following use cases:
> > a) Local component development (C++, Confix)
> > b) Local and remote component development (C++, Confix, Mico)
>
> I dunno, I think it would be cleaner from the user's perspective to have
> a single ccmtools-c++-generate script. Users could just add a --remote
> switch (or something like that) to the call if they will be generating
> remote component code in addition to the local stuff.
>
> ... But I can see how if you've already generated the local code it
> would be a pain to regenerate the local code just to get the remote
> code. Whatever works.
>
> Gotta run to help some kids with math homework. Cheers !
>
> leif
>
> --
> Leif Morgan Johnson : http://ambient.2y.net/leif/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> ccmtools-devel mailing list
> ccm...@li...
> https://lists.sourceforge.net/lists/listinfo/ccmtools-devel
>
|
|
From: Leif J. <le...@am...> - 2003-11-20 19:15:58
|
Hi all - I just set up a mailing list that will send out mail every time someone commits something to CVS. This list will be a good way to keep track of which developers are working on which parts of the tools. List traffic will depend on how heavy development is---we'll get one message per `cvs commit' command. Make sure your cvs log messages are good, too, because other people will read them. :) To subscribe point your web browser to : https://lists.sourceforge.net/lists/listinfo/ccmtools-cvs and just fill in the blanks. leif -- Leif Morgan Johnson : http://ambient.2y.net/leif/ |
|
From: Leif J. <le...@am...> - 2003-11-19 22:20:52
|
Hi Egon -
I went on a tour de force today and merged the _user_types and
_basic_types tests together. Since the CCM Tools no longer has they
`user' or `basic' type distinction, I thought it would be cleaner to
merge the tests. I'm doing make check right now, will let you know how
it turns out.
Also, what do you think of merging the _interface tests in with the
_types tests ? Seems like an interface is just another type, no ?
I also removed some of the basic tests that were already covered by the
_types tests. I noticed a couple of _check_CCM_Remote_*.cc test files
getting removed, I'm sorry if I got rid of the tests that you're trying
to merge in from the remote generator. :-/ We'll get it worked out
though.
I think I'm going to set up a new ccmtools mailing list, ccmtools-cvs,
which will send us an email whenever people commit something to cvs.
Would be a nice way to keep track of what everyone's working on.
On Wed, 19 Nov 2003, Egon Teiniker wrote:
> Quoting Leif Johnson <le...@am...>:
> > Why don't we create the remote environment when we create the local
> > environment, and get rid of the ccmtools-c++remote-* scripts ? We can
> > add a switch to the ccmtools-c++-{environment|generate} scripts to do
> > the remote environment, components and tests. There's already a switch
> > in there for the Python wrappers ; it just isn't used at the moment.
> > Comments ?
>
> I think that installing and using the local components is much easier
> (no CORBA) that handling remote components. Thus, local components can
> be the gateway drug to CCM ;-) After that the remote stuff is just
> another step...
>
> So I think that we should separate the following use cases:
> a) Local component development (C++, Confix)
> b) Local and remote component development (C++, Confix, Mico)
I dunno, I think it would be cleaner from the user's perspective to have
a single ccmtools-c++-generate script. Users could just add a --remote
switch (or something like that) to the call if they will be generating
remote component code in addition to the local stuff.
... But I can see how if you've already generated the local code it
would be a pain to regenerate the local code just to get the remote
code. Whatever works.
Gotta run to help some kids with math homework. Cheers !
leif
--
Leif Morgan Johnson : http://ambient.2y.net/leif/
|
|
From: Teiniker E. <ego...@tu...> - 2003-11-19 16:02:17
|
Hi Leif!
Quoting Leif Johnson <le...@am...>:
> 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?
>
> Why don't we create the remote environment when we create the local
> environment, and get rid of the ccmtools-c++remote-* scripts ? We can
> add a switch to the ccmtools-c++-{environment|generate} scripts to do
> the remote environment, components and tests. There's already a switch
> in there for the Python wrappers ; it just isn't used at the moment.
> Comments ?
I think that installing and using the local components is much easier (no CORBA)
that handling remote components. Thus, local components can be the gateway drug
to CCM ;-) After that the remote stuff is just another step...
So I think that we should separate the following use cases:
a) Local component development (C++, Confix)
b) Local and remote component development (C++, Confix, Mico)
:-) Egon
|
|
From: Teiniker E. <ego...@tu...> - 2003-11-19 15:54:28
|
Hey Leif! Quoting Leif Johnson <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. Yes, I agree - therefore, I added the existing remote tests in the test/CppGenerator tree. Tomorrow, I will remove the whole test/CppRemoteGenerator tree from the project. > 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). Excellent, I will adapt the ccmtools tutorial in that way... I also think that we can leave out some simple (redundant) test cases, e.g. facet, supports, attribute, etc. > 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). Yes, that is a good idea. :-) Egon |
|
From: Leif J. <le...@am...> - 2003-11-18 22:50:00
|
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?
Why don't we create the remote environment when we create the local
environment, and get rid of the ccmtools-c++remote-* scripts ? We can
add a switch to the ccmtools-c++-{environment|generate} scripts to do
the remote environment, components and tests. There's already a switch
in there for the Python wrappers ; it just isn't used at the moment.
Comments ?
leif
--
Leif Morgan Johnson : http://ambient.2y.net/leif/
|
|
From: Leif J. <le...@am...> - 2003-11-18 22:27:30
|
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/
|
|
From: Teiniker E. <ego...@tu...> - 2003-11-18 17:30:06
|
Hey Leif! 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? 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... :-) Egon |
|
From: Teiniker E. <ego...@tu...> - 2003-11-17 15:07:11
|
Hi all! Today, I have integrated my offline version of the CppRemoteGenerator with t= he current version of the ccmtools-0.3.3. I also added a test/CppRemoteGenerator directory with some subdirectories containing lightweight remote test cases (_check_*_remote.cc files). Note that these tests are not yet integrated in the automated make check procedure, but I have manually run the following tests: > ccmtools-c++-generate -d -a -p xxx Hello.idl > ccmtools-c++remote-generate -d -p xxx Hello.idl > ccmtools-c++-configure -p xxx > ccmtools-c++-make -p xxx - facet OK - facet_basic_types OK - facet_exception OK - attribute OK - attribute_basic_types OK - supports OK - supports_basic_types OK To automate these tests, we need a Confix version that can install *.idl fil= es - J=F6rg is working on this topic... I have also changed the CodeGenerator.java file. To make the remote generato= r run I have (re)implemented the getBaseIdlType() method. :-) Egon |
|
From: Teiniker E. <ego...@tu...> - 2003-11-15 19:35:44
|
Hey Leif! Quoting Leif Johnson <le...@am...>: > > I have added and updated some files for the Cpp-Remote-Generator - it > > compiles, but it does not work well. Don't care about it, I will fix > > it in the next couple of days. Working with remote components is a > > good chance to find possible bugs in the IDL2 generator... > > Excellent. Looking forward to it. When we have a functional remote > generator we can really start to publicize the CCM Tools as a > full-fledged CORBA component generator toolset ! Yes, I guess that I can make the remote generator run in the next week... So, be ready to install the mico ORB ;-) > I'm working on the Python wrapper generator, leaning towards using SWIG > like J=F6rg pointed out. SWIG is quite nice ! Excellent! Have a nice weekend. :-) Egon |
|
From: Teiniker E. <ego...@tu...> - 2003-11-15 19:29:24
|
Hey Leif! Quoting Leif Johnson <le...@am...>: > Did you have a look at CodeGenerator/Driver.java and > UI/ConsoleDriverImpl.java ? I think that interface and class provide the > functionality you're looking for in the Debug class, or at least that's > what I intended by them. But just a thought. Yes you are right! This Debug class was just thought as a first step in the direction of an explicit ccmtools.utils package that collects all the utility classes around the ccmtools... > Also, did you want to remove the CCD generator from the source tree ? I > can't make the ccmtools because test/CCDGenerator/Makefile.am is missing > (no longer in CVS). Or did I do that accidentally ? Sorry for breaking the build process... I wanted to disable the building of the CCDGenerator because it has never been used in the ccmtools - probably I forgot to commit the changes I made in the test/Makefile.am. I did not remove the CCDGenerator source code because it could be reused in a future component descriptor generator. :-) Egon |
|
From: Leif J. <le...@am...> - 2003-11-15 02:51:07
|
Egon - Did you have a look at CodeGenerator/Driver.java and UI/ConsoleDriverImpl.java ? I think that interface and class provide the functionality you're looking for in the Debug class, or at least that's what I intended by them. But just a thought. Also, did you want to remove the CCD generator from the source tree ? I can't make the ccmtools because test/CCDGenerator/Makefile.am is missing (no longer in CVS). Or did I do that accidentally ? leif -- Leif Morgan Johnson : http://ambient.2y.net/leif/ |
|
From: Leif J. <le...@am...> - 2003-11-15 02:15:19
|
Hi hi - On Thu, 13 Nov 2003, Egon Teiniker wrote: > I have added and updated some files for the Cpp-Remote-Generator - it > compiles, but it does not work well. Don't care about it, I will fix > it in the next couple of days. Working with remote components is a > good chance to find possible bugs in the IDL2 generator... Excellent. Looking forward to it. When we have a functional remote generator we can really start to publicize the CCM Tools as a full-fledged CORBA component generator toolset ! I'm working on the Python wrapper generator, leaning towards using SWIG like J=C3=B6rg pointed out. SWIG is quite nice ! > I also changed the ConsoleCodeGenerator.java file to show the cpp > error messages. ROCK ! I've been wondering how to do this ... Thanks ! leif -- Leif Morgan Johnson : http://ambient.2y.net/leif/ |
|
From: Teiniker E. <ego...@tu...> - 2003-11-13 17:57:35
|
Hi Leif! I have added and updated some files for the Cpp-Remote-Generator - it compiles, but it does not work well. Don't care about it, I will fix it in the next couple of days. Working with remote components is a good chance to find possible bugs in the IDL2 generator... I also changed the ConsoleCodeGenerator.java file to show the cpp error messages. :-) Egon |
|
From: Joerg F. <jf...@ao...> - 2003-11-12 17:41:57
|
>>>>> "Leif" == Leif Johnson <le...@am...> writes:
>> If we had a SWIG interface generator, we'd get the Python wrapper for
>> free, along with other languages.
Leif> Yessssss ...
>> Well, almost: we'd only have to convince Confix to build that stuff
>> :-). It shouldn't be that hard though.
>>
>> Could that be an option?
Leif> You mean as part of the CCM Tools or part of Confix ? Both ?
Leif> It definitely doesn't seem like it would be difficult to generate SWIG
Leif> interface files. But what about calling SWIG with Confix ? I suppose we
Leif> could do that in the Makefile.py ?
Yes. It's currently a bit halfbaked, but Confix is moving in that
direction. To invoke orbit-idl-2 on an installed IDL file (currently
all IDL files are installed into $(includedir), and nothing else is
done with them automatically), you write in a module's Makefile.py,
from libconfix.plugin_salomon_idl import BuildableSalomonIDL
BUILDABLES_.append(BuildableSalomonIDL(dir=MODULE_.dir(),
idlfile='lvs_svr_idl.idl'))
With this you register one header file and three C files as
BUILT_SOURCES, build them into $(builddir), and collapse them into a
library as the outcome of the module's build. Substitute SWIG for IDL,
remove Salomon, and the same applies for any language wrappers that
SWIG supports. Theoretically.
What remains to be done is
- Polish the plugin interface, so that nobody has to mess with the
internals of module_iface.
- Decouple the actual location of $(includedir) from the source
scanning process since $(includedir) may not contain anything
meaningful at that time. Anything that counts at that time should be
the repo. Advanced stuff here; I'd like to try to keep the repo
stuff and automake two completely different things. Note that the
problem does not occur when you are building from an IDL file in
$(srcdir) because then you have the source available at any time -
the complicated stuff is building from installed files that you are
not guaranteed to see at scan time. But, unfortunately, that's the
general case.
Anyway, I'm confident that I'll get it right real soon now (TM).
Joerg
|
|
From: Leif J. <le...@am...> - 2003-11-11 20:39:30
|
Hi all -
Please note that all generated IDL files---mirror files, IDL2 files,
whatever---have the same suffix (.idl). Previously, the generated files
had different suffixes to avoid name collisions, but they didn't work
with our include file tests. I didn't see any other way of fixing the
tests. Just make sure you don't generate IDL3Mirror files and IDL2 files
in the same directory.
Also, to get an idea of the development process for included files
(which I assume will be the majority of real development situations)
have a look at the test/CppGenerator/{include|test-loader}.sh scripts.
Just set up your development environment (PATH and CLASSPATH, template
directories, etc.), then make and install the external files, then make
and install the files you're developing.
leif
--
Leif Morgan Johnson : http://ambient.2y.net/leif/
|
|
From: Leif J. <le...@am...> - 2003-11-11 20:20:20
|
On Tue, 11 Nov 2003, Joerg Faschingbauer wrote: > >>>>> "Leif" == Leif Johnson <le...@am...> writes: > > Leif> Oh well, pipe dreams. I'm working this week on the Python wrapper > Leif> generator for C++ components. > > Recently, I skimmed through the SWIG manual. Impressive. Yeah, I think so, too. I haven't had much of a chance to try it out, but it generated a Python wrapper for the pgapack (parallel genetic algorithm) library quite handily. > If we had a SWIG interface generator, we'd get the Python wrapper for > free, along with other languages. Yessssss ... > Well, almost: we'd only have to convince Confix to build that stuff > :-). It shouldn't be that hard though. > > Could that be an option? You mean as part of the CCM Tools or part of Confix ? Both ? It definitely doesn't seem like it would be difficult to generate SWIG interface files. But what about calling SWIG with Confix ? I suppose we could do that in the Makefile.py ? leif -- Leif Morgan Johnson : http://ambient.2y.net/leif/ |
|
From: Leif J. <le...@am...> - 2003-11-11 20:08:39
|
On Tue, 11 Nov 2003, Egon Teiniker wrote: > The IDL2 generator creates code for IDL sequences which are defined in > included files. > > Example: (see attachments) > groupdata.idl: contains a struct and a sequence of struct > groupmgr.idl: includes groupdata.idl and uses the sequence of struct. > If I generate only groupmgr.idl, the sequence def file is also created. Hmm ... the sequence is generated but the GroupData struct isn't ? Sounds like a parser issue to me. I'll have a look at it. leif -- Leif Morgan Johnson : http://ambient.2y.net/leif/ |
|
From: Teiniker E. <ego...@tu...> - 2003-11-11 14:10:42
|
Hey Leif! The IDL2 generator creates code for IDL sequences which are defined in included files. Example: (see attachments) groupdata.idl: contains a struct and a sequence of struct groupmgr.idl: includes groupdata.idl and uses the sequence of struct. If I generate only groupmgr.idl, the sequence def file is also created. Do you have an idea about that? :-) Egon |
|
From: Teiniker E. <ego...@tu...> - 2003-11-11 10:40:41
|
Hi all! I have added a python script that is a wrapper for IDL compiler calls (see ccmtools-idl -h). Using a --mico or --java option we can switch between these IDL compilers, and the ccmtools-idl script can also handle *.idl parameters. There are also some changes in IDL2 templates: *) The MHomeDef includes the MComponentDef IDL file, thus we don't need any forward declarations of component interfaces. *) The MComponentDef does not include the MHomeDef IDL file. *) The generated Makefile uses the ccmtools-idl script to call the mico IDL compiler for all generated IDL2 files. In the next few days I will run some other IDL2 generator tests... :-) Egon |
|
From: Joerg F. <jf...@ao...> - 2003-11-11 08:14:23
|
>>>>> "Leif" == Leif Johnson <le...@am...> writes: Leif> Oh well, pipe dreams. I'm working this week on the Python wrapper Leif> generator for C++ components. Recently, I skimmed through the SWIG manual. Impressive. If we had a SWIG interface generator, we'd get the Python wrapper for free, along with other languages. Well, almost: we'd only have to convince Confix to build that stuff :-). It shouldn't be that hard though. I'm currently writing a lot of Salomon specific plugins for code generators they are using in a project. The one I'm just working on invokes orbit-idl-2 on an installed IDL file to generate four C source files into the local build. Sounds a lot like invoking SWIG on an installed SWIG interface file. Could that be an option? Cheers, Joerg |
