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: Leif J. <le...@am...> - 2003-11-11 07:46:14
|
Today I converted CCMMOFGraphTraverser.java and CodeGenerator.java to
Python (all on a separate CVS branch, not to worry :). I came up with a
nifty script for doing a lot of the converting from Java to Python
(attached :) but still had some work to do. After these two files,
though, I discovered that it's not really worth the hassle !
Doing a line, word, and byte count on the respective files yields :
1118 5279 45933 CodeGenerator.java
963 3869 35390 CodeGenerator.py
231 1030 8538 CCMMOFGraphTraverserImpl.java
159 719 5890 CCMMOFGraphTraverserImpl.py
This doesn't reflect actual executed code size, because the bulk of both
files is contained in comments. But a mere 33 % decrease---not too
impressive. I think everyone knows I like Python better than Java, but
they turned out to be more equivalent than I thought.
That said, it would be nice if Java had a lambda keyword and map
function for sequences. For example, the following Java :
MInterfaceDef iface = (MInterfaceDef) current_node;
List bases = new ArrayList();
for (Iterator i = iface.getBases().iterator(); i.hasNext(); )
bases.add(getScopedInclude((MInterfaceDef) i.next()));
value = join("\n", bases);
is much more elegantly expressed in Python as :
value = '\n'.join(map(lambda b: getScopedInclude(b),
current_node.getBases()))
(That's a 60 % decrease in size.) Lambda keywords, ahhhh.
Oh well, pipe dreams. I'm working this week on the Python wrapper
generator for C++ components.
leif
--
Leif Morgan Johnson : http://ambient.2y.net/leif/
|
|
From: Leif J. <le...@am...> - 2003-11-03 07:10:14
|
Hi component fans ! It turns out that the really tricky test in this go-round of the development cycle was a simple one : it was facet_rename, where an existing test failed when its respective components and interfaces were renamed. The problem was related to include files and how the parser labeled original-source-file nodes, so the solution was actually an improved IDL3 parser, and a slight change in the IDL3 mirror templates. At any rate, the ccmtools have now passed all tests. This means two things : 1. We don't have enough tests. :) I imagine we'll improve this when we get some more users in January. 2. I am running make distcheck tonight and will do a release (0.3.2) tomorrow. Improved documentation, remote wrappers, and python wrappers will be focal points of the next (0.3.3) release. Also note that the localComponents/CCM.h header file has changed slightly, to accomodate some exceptions with string constructors. This has improved the mirror component test generator somewhat. Anyway, that's the news from northern California, where we have a governator. Hope everyone's doing well. leif -- Leif Morgan Johnson : http://ambient.2y.net/leif/ |
|
From: Teiniker E. <ego...@tu...> - 2003-10-23 17:34:46
|
Hi all! After a request of Robert Lechner, I added a test case that does not run... The new test case is called: facet_rename.sh The problem is that the facet example does not compile after renaming component and component home in the Hello.idl file! I think that is template stuff, so I will try to fix it. :-) Egon |
|
From: Joerg F. <jf...@sa...> - 2003-10-23 13:49:56
|
>>>>> "Leif" == Leif Johnson <le...@am...> writes: Leif> On Tue, 21 Oct 2003, Joerg Faschingbauer wrote: >> >>>>> "Leif" == Leif Johnson <le...@am...> writes: >> Leif> - receptacle_not_connected : Fails because one of its _check_*.cc files Leif> does `assert(false)'. Other than this check, everything (generation, Leif> compilation, etc.) works fine. Should we put this test in XFAIL Leif> instead of TEST, since we expect it to fail ? Does Confix provide Leif> automatic handling for XFAIL tests ? >> >> Not yet. I just filed a feature request, >> though. https://sourceforge.net/tracker/index.php?func=detail&aid=827331&group_id=68975&atid=523022 Leif> At the risk of breaking Confix again today, I've implemented what looks Leif> like a solution to me. Patch attached, though I haven't tested it. Let Leif> me know if it's ok to check this in. Doesn't smell like breakage, at least as long as we don't see any _xfail_check*.cc files :-) When you've checked it in, could you please add a comment to the feature request? Just a reminder that there is a BuildableModule.add_am_xfail_check_program() method already, nothing more. Thanks, Joerg |
|
From: Teiniker E. <ego...@tu...> - 2003-10-23 09:22:39
|
Hey Leif! I added the following test cases to check the usage of (smart pointer) interfaces within components: supports_interface.sh facet_interface.sh receptacle_interface.sh The business-logic code (test/CppGenerator/*/src and */CCM_Test) for these tests will follow... To fix the problem with interface parameters, I changed the CppGenerator.java / getLanguageType() method. The make check results: 4 of 40 tests failed FAIL: supports-inheritance.sh FAIL: facet-inheritance.sh FAIL: receptacle-inheritance.sh FAIL: module_mixed.sh :-) Egon |
|
From: Leif J. <le...@am...> - 2003-10-22 19:54:30
|
On Tue, 21 Oct 2003, Joerg Faschingbauer wrote: > >>>>> "Leif" =3D=3D Leif Johnson <le...@am...> writes: > > Leif> - receptacle_not_connected : Fails because one of its _check_*.cc f= iles > Leif> does `assert(false)'. Other than this check, everything (generati= on, > Leif> compilation, etc.) works fine. Should we put this test in XFAIL > Leif> instead of TEST, since we expect it to fail ? Does Confix provide > Leif> automatic handling for XFAIL tests ? > > Not yet. I just filed a feature request, > though. https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D827= 331&group_id=3D68975&atid=3D523022 At the risk of breaking Confix again today, I've implemented what looks like a solution to me. Patch attached, though I haven't tested it. Let me know if it's ok to check this in. Now we just have to figure out a way to generate _xfail_check*.cc files =66rom the CCM Tools. :-( leif -- Leif Morgan Johnson : http://ambient.2y.net/leif/ |
|
From: Teiniker E. <ego...@tu...> - 2003-10-22 18:31:19
|
Hey Leif! The attribute_interface.sh test is running now! make check results in 5 of 37 tests failed FAIL: supports-inheritance.sh FAIL: facet-inheritance.sh FAIL: receptacle-inheritance.sh FAIL: home-factory-interface.sh FAIL: module_mixed.sh I checked in the changes I made. :-) Egon |
|
From: Leif J. <le...@am...> - 2003-10-22 11:25:44
|
Word. On Tue, 21 Oct 2003, Egon Teiniker wrote: > I fixed the bugs in the following tests: > *) receptacle_not_connected.sh > *) supports_user_types.sh > *) facet_user_types.sh Rock ! > Thus, the result of make check is: > 6 of 37 tests failed > FAIL: attribute-interface.sh > FAIL: supports-inheritance.sh > FAIL: facet-inheritance.sh > FAIL: receptacle-inheritance.sh > FAIL: home-factory-interface.sh > FAIL: module_mixed.sh Success : 83.78 % (for Kristian). I'm working on the -inheritance.sh tests. The module_mixed.sh test baffles me. > I will do the smartpointer++ stuff tomorrow. Today I did not have the > time because I produced some hot air... Excellent. (Not the hot air, but the smartpointer stuff.) > PS: Have you hacked Confix to add a --quiet option? The ccmtools-c++-* > scripts did not work on my box using Confix-1.3pre11. Oops. I just checked in the changes to Confix. :-} leif -- Leif Morgan Johnson : http://ambient.2y.net/leif/ |
|
From: Joerg F. <jf...@sa...> - 2003-10-21 07:31:25
|
>>>>> "Leif" == Leif Johnson <le...@am...> writes: Leif> - receptacle_not_connected : Fails because one of its _check_*.cc files Leif> does `assert(false)'. Other than this check, everything (generation, Leif> compilation, etc.) works fine. Should we put this test in XFAIL Leif> instead of TEST, since we expect it to fail ? Does Confix provide Leif> automatic handling for XFAIL tests ? Not yet. I just filed a feature request, though. https://sourceforge.net/tracker/index.php?func=detail&aid=827331&group_id=68975&atid=523022 Joerg |
|
From: Leif J. <le...@am...> - 2003-10-20 23:35:47
|
Hi all -
These are the results when I do the C++ tests (I got this by doing `make
check > /tmp/ccmtools.log 2>&1' and then doing `grep 'PASS\|FAIL'
/tmp/ccmtools/log') :
PASS: help.sh
PASS: version.sh
PASS: attribute_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: attribute.sh
FAIL: attribute-interface.sh
PASS: supports_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: supports.sh
PASS: facet_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: facet.sh
PASS: receptacle_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: receptacle.sh
FAIL: receptacle_not_connected_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: receptacle_not_connected_CCM_Test__check_CCM_Session_Hello
FAIL: receptacle_not_connected.sh
PASS: receptacle_multiple_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: receptacle_multiple.sh
PASS: attribute_basic_types_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: attribute_basic_types.sh
PASS: supports_basic_types_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: supports_basic_types.sh
PASS: facet_basic_types_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: facet_basic_types.sh
PASS: receptacle_basic_types_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: receptacle_basic_types.sh
PASS: home_basic_types_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: home_basic_types.sh
PASS: attribute_user_types_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: attribute_user_types.sh
FAIL: supports_user_types_CCM_Test__check_CCM_Local_CCM_Session_Hello
FAIL: supports_user_types.sh
FAIL: facet_user_types_CCM_Test__check_CCM_Local_CCM_Session_Hello
FAIL: facet_user_types.sh
PASS: receptacle_user_types_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: receptacle_user_types.sh
PASS: home_user_types_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: home_user_types.sh
PASS: supports_exception_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: supports_exception.sh
PASS: facet_exception_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: facet_exception.sh
PASS: receptacle_exception_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: receptacle_exception.sh
PASS: home_exception_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: home_exception.sh
FAIL: supports-inheritance.sh
FAIL: facet-inheritance.sh
FAIL: receptacle-inheritance.sh
PASS: home_factory_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: home_factory.sh
FAIL: home-factory-interface.sh
PASS: include_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: include.sh
PASS: include_dir_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: include_dir.sh
PASS: include_nested_CCM_Test__check_CCM_Local_CCM_Session_Hello
PASS: include_nested.sh
PASS: module_CCM_Test__check_CCM_Local_WORLD_CCM_Session_Hello
PASS: module.sh
PASS: module-nested_CCM_Test__check_CCM_Local_WORLD_Europe_austria_CCM_Session_Hello
PASS: module-nested.sh
PASS: module-reopen_CCM_Test__check_CCM_Local_WORLD_CCM_Session_Hello
PASS: module-reopen.sh
FAIL: module_mixed.sh
PASS: Calculator_CCM_Test__check_CCM_Local_CCM_Session_Calculator
PASS: Calculator_CCM_Test__check_CCM_Local_CCM_Session_Display
PASS: Calculator_CCM_Test__check_CCM_Local_CCM_Session_IntegerCalculator
PASS: calculator.sh
PASS: owudb.sh
Lots of passes ! Still some failures though. :(
So, some notes :
- attribute-interface and home-factory-interface : Fail because they try
to pass an interface as a parameter, which doesn't work in C++ with
abstract base classes. Waiting for smartptr++.
- receptacle_not_connected : Fails because one of its _check_*.cc files
does `assert(false)'. Other than this check, everything (generation,
compilation, etc.) works fine. Should we put this test in XFAIL
instead of TEST, since we expect it to fail ? Does Confix provide
automatic handling for XFAIL tests ?
- {supports|facet}_user_types : Fail because one of the operations
apparently doesn't do the expected task. Note that the code generates
and compiles, it's just the component checks that fail on `assert
(Array_r.at(i) == i)'. I looked at the code but couldn't find anything
obviously wrong. Any help here ?
- module_mixed : Fails for some unknown reason when parsing the
generated idl3mirror files. Any suggestions ?
- supports-inheritance, facet-inheritance, receptacle-inheritance : Fail
because interfaces don't automatically include operations from base
interfaces when traversing the metamodel graph. So components that
involve an interface that has base interfaces (whew !) end up having
pure virtual operations in generated C++ code.
This last issue is a somewhat serious bug. I'm actually thinking about a
slight Metamodel change that could fix this---a call to
iface.getContentss() could automatically include operations from base
interfaces ... any thoughts ?
Cheers,
leif
--
Leif Morgan Johnson : http://ambient.2y.net/leif/
|
|
From: Leif J. <le...@am...> - 2003-10-19 09:59:20
|
On Sat, 18 Oct 2003, Robert Lechner wrote: > Teiniker Egon wrote: > >> - facet, receptacle, facet_basic_types, receptacle_basic_types : > >> Didn't compile because my compiler complained about `assert' in > >> src/Hello_mirror_app.cc. I added `#include <assert>' but haven't > >> gotten a chance to test that it works. > > > > Hmm, my compiler does not matter about it but a student of mine has > > had the problem and fixed it with #include<cassert> I think. > > I added > > #include <assert.h> > > to 'CCM_Utils/Debug.h'. That solved the problem. Excellent. I've been adding `#include <cassert>', but on my linux box, the /usr/include/c++/3.2/cassert header file contains a single line : `#include <assert.h>'. :) I've been squashing bugs in the ccmtools this weekend ... there have been lots of simple errors generating the proper #include statements. Also, all of the user_types tests were failing because of a one-word typo---doh ! And the IDL syntax for array typedefs is quite strange, had to do a little hacking to fix that up. So on my box 20 of the 37 C++ tests pass now, and I hope to get about 10 more to pass by the end of the weekend. Looks like there are about 5 tests that barf when trying to pass an abstract base class by value, we'll have to wait for the smartpointer++ to fix those. Cheers ! leif -- Leif Morgan Johnson : http://ambient.2y.net/leif/ |
|
From: Robert L. <rle...@sb...> - 2003-10-18 12:42:41
|
Teiniker Egon wrote: >> - facet, receptacle, facet_basic_types, receptacle_basic_types : >> Didn't compile because my compiler complained about `assert' in >> src/Hello_mirror_app.cc. I added `#include <assert>' but haven't >> gotten a chance to test that it works. > > Hmm, my compiler does not matter about it but a student of mine has > had the problem and fixed it with #include<cassert> I think. I added #include <assert.h> to 'CCM_Utils/Debug.h'. That solved the problem. -- -- Robert Lechner, rle...@sb... -- |
|
From: Teiniker E. <ego...@tu...> - 2003-10-17 12:32:08
|
Hey Leif! Quoting Leif Johnson <le...@am...>: > But here are the things I've noticed so far > about the tests : > > - facet, receptacle, facet_basic_types, receptacle_basic_types : Didn't > compile because my compiler complained about `assert' in > src/Hello_mirror_app.cc. I added `#include <assert>' but haven't > gotten a chance to test that it works. Hmm, my compiler does not matter about it but a student of mine has had the problem and fixed it with #include<cassert> I think. > - attribute_interface : Apparently my compiler (g++ 3.2) isn't happy > about functions that return an abstract base class (i.e. an > interface). In general, C++ seemed to be an unhappy language (hey J=F6rg it's a joke ;-) We have to pass the abstract classes by reference instead by value. To handl= e the memory management we will use SmartPtr. Don't care about that problem, I will fix it in the next week. > - receptacle_multiple : The %(Identifier)sConnections type definition > for multiple receptacles somehow got lost in the shuffle. I tried to > define it in the MUsesDefIncludeMultiple template as : > > typedef std::vector<CCM_Local::%(UsesType)s> %(Identifier)sConnections= ; > > but it looks like this isn't quite right. I think maybe there was a > SmartPtr<CCM_Local::%(UsesType)s> in there or something. Could you fix > this up for me ? OK, I have added the following lines to the MUsesDefIncludeMultiple template= : #ifndef __MAPPING__%(UsesType)s__%(Identifier)s__ #define __MAPPING__%(UsesType)s__%(Identifier)s__ typedef std::map<localComponents::Cookie, CCM_Utils::SmartPtr<CCM_Local::CCM_%(UsesType)s> > %(Identifier)sConnections= ; #endif I also added a src/ subdirectory to test/CppGenerator/receptacle_multiple, t= hus the receptacle_multiple.sh test passes the check now. The problems in the home_factory.sh and home_basic_types.sh tests are also fixed. > I noticed the _user_types tests didn't even generate code ; I'll work on > that tomorrow. Excellent! As soon as the IDL user types can be generated, I will add the remote compon= ent generator stuff to bring all the code together. :-) Egon |
|
From: Leif J. <le...@am...> - 2003-10-17 04:32:20
|
Hi Egon and company -
I'm really glad you fixed whatever was wrong with the linker versioning
stuff. It was blocking me from linking the C++ generator tests. I'm
pleased that the tests are compiling and running again !
I've been trying to run make check in the CppGenerator directory. It's
taking a while because my pooter is quite slow (and I'm also ripping /
encoding some CDs ... :-). But here are the things I've noticed so far
about the tests :
- facet, receptacle, facet_basic_types, receptacle_basic_types : Didn't
compile because my compiler complained about `assert' in
src/Hello_mirror_app.cc. I added `#include <assert>' but haven't
gotten a chance to test that it works.
- attribute_interface : Apparently my compiler (g++ 3.2) isn't happy
about functions that return an abstract base class (i.e. an
interface). My compiler barfs with the following error :
In file included from /home/leif/src/ccmtools/head/test/CppGenerator/sandbox/attribute_interface/src/Hello_app.h:9,
from /home/leif/src/ccmtools/head/test/CppGenerator/sandbox/attribute_interface/src/HelloHome_app.cc:9:
../CCM_Local_CCM_Session_Hello_share/include/CCM_Local/CCM_Session_Hello/Hello_share.h:36: error: invalid return type for member function `virtual CCM_Local::ACommon CCM_Local::CCM_Session_Hello::CCM_Hello::the_a()'
../CCM_Local_CCM_Session_Hello_share/include/CCM_Local/CCM_Session_Hello/Hello_share.h:36: error: because the following virtual functions are abstract:
../CCM_Local/include/CCM_Local/ACommon.h:30: error: virtual void CCM_Local::ACommon::set_attrib_a(long int)
../CCM_Local/include/CCM_Local/ACommon.h:31: error: virtual long int CCM_Local::ACommon::get_attrib_b()
This is a bit disconcerting ... we might have to implement IDL
interfaces in C++ using something other than an abstract base class ?
- receptacle_multiple : The %(Identifier)sConnections type definition
for multiple receptacles somehow got lost in the shuffle. I tried to
define it in the MUsesDefIncludeMultiple template as :
typedef std::vector<CCM_Local::%(UsesType)s> %(Identifier)sConnections;
but it looks like this isn't quite right. I think maybe there was a
SmartPtr<CCM_Local::%(UsesType)s> in there or something. Could you fix
this up for me ?
That's all I've got time for at the moment.
I noticed the _user_types tests didn't even generate code ; I'll work on
that tomorrow. Cheers !
leif
On Wed, 15 Oct 2003, Egon Teiniker wrote:
> Hi all!
>
> I updated the test-loader.sh script and added src and CCM_Local sub-directories
> to the test/cppGenerator/* directories.
> After that, the following tests passes the check:
> - attribute.sh
> - supports.sh
> - facet.sh
> - receptacle.sh
> - attribute_basic_types.sh
> - supports_basic_types.sh
> - facet_basic_types.sh
> - receptacle_basic_types.sh
> - include.sh
> - include_dir.sh
> - module.sh
> - module-nested.sh
> There are some problems while testing home_basic_types.sh and home_factory.sh -
> I will fix it tomorrow...
>
> Hey Leif, what's the current status with the local C++ generator for complex
> types ( attribute_user_types, facet_user_types, etc.) ?
>
> :-) Egon
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> ccmtools-devel mailing list
> ccm...@li...
> https://lists.sourceforge.net/lists/listinfo/ccmtools-devel
--
Leif Morgan Johnson : http://ambient.2y.net/leif/
|
|
From: Joerg F. <jf...@sa...> - 2003-10-16 12:33:09
|
>>>>> "Egon" =3D=3D Teiniker Egon <ego...@tu...> writes: Egon> There was a bug in the CppLocalTemplates/SmartPointerImpl templat= e that causes a Egon> linker error when building components. Egon> Until now, I did not notice the bug because I used an older versi= on of the local Egon> component environment. Egon> After a confix update I have deleted the old version and made a n= ew one - bingo! Egon> J=F6rg told me how to fix the bug, thus the local component envir= onment is working Egon> well now. In case you are interested in the unresolved symbol, and you want to know why this symbol exists (as opposed to "not exists" :-), you may want to read the comment in the attached file. Joerg |
|
From: Teiniker E. <ego...@tu...> - 2003-10-16 09:52:40
|
Hi all! There was a bug in the CppLocalTemplates/SmartPointerImpl template that caus= es a linker error when building components. Until now, I did not notice the bug because I used an older version of the l= ocal component environment. After a confix update I have deleted the old version and made a new one - bi= ngo! J=F6rg told me how to fix the bug, thus the local component environment is w= orking well now. :-) Egon |
|
From: Joerg F. <jf...@sa...> - 2003-10-16 08:15:48
|
Hi, I just made another Confix 1.3 prerelease. No great changes, except that you can now add files to the EXTRA_DIST variables in the Makefile.am of the package and module, by using the respective EXTRA_DIST() functions. I also documented these (:-), see the function index of the manual. Joerg |
|
From: Teiniker E. <ego...@tu...> - 2003-10-15 15:07:24
|
Hi all! I updated the test-loader.sh script and added src and CCM_Local sub-directories to the test/cppGenerator/* directories. After that, the following tests passes the check: - attribute.sh - supports.sh - facet.sh - receptacle.sh - attribute_basic_types.sh - supports_basic_types.sh - facet_basic_types.sh - receptacle_basic_types.sh - include.sh - include_dir.sh - module.sh - module-nested.sh There are some problems while testing home_basic_types.sh and home_factory.sh - I will fix it tomorrow... Hey Leif, what's the current status with the local C++ generator for complex types ( attribute_user_types, facet_user_types, etc.) ? :-) Egon |
|
From: Teiniker E. <ego...@tu...> - 2003-10-14 16:32:15
|
Hi all! The ccmtools-c++-generate script has changed in the following ways: *) I modified the CCMTOOLS_PACKAGE = 'ccmtools-package' definition to CCMTOOLS_PACKAGE = '.' Thus, the generated CCM_* directories can be put into the current directory which plays the role of confix' package root. Of course, you can still use the -p option to specify a particular package root. *) To save the *_app.* files from overwriting, no *_app.* files are generated by default. A component developer has to set the -a (--application) option explicitly to force the ccmtools-c++-generate script to create these files. :-) Egon PS: Tomorrow I will try to change the test scripts... |
|
From: Leif J. <le...@am...> - 2003-10-13 21:00:32
|
On Mon, 13 Oct 2003, Egon Teiniker wrote: > I changed the MHomeDef and MComponentDef templates to fill the > *_shared.h files.I also changed the ccmtools-c++-generate, > ccmtools-c++-configure and ccmtools-c++-make scripts to undo the > *_app.* file copy. Finally, I added a src/ directory to the > test/CppGenerator/facet and test/CppGenerator/facet_basic_types > directory. ROCK ! Thanks Egon ! leif -- Leif Morgan Johnson : http://ambient.2y.net/leif/ |
|
From: Teiniker E. <ego...@tu...> - 2003-10-13 13:41:17
|
Hey all!
I changed the MHomeDef and MComponentDef templates to fill the *_shared.h
files.I also changed the ccmtools-c++-generate, ccmtools-c++-configure and
ccmtools-c++-make scripts to undo the *_app.* file copy.
Finally, I added a src/ directory to the test/CppGenerator/facet and
test/CppGenerator/facet_basic_types directory.
To show the changes in component development, let's make an example:
> cd test/idl/facet
> ccmtools-c++-generate -d -p hello Hello.idl
> tree hello
hello/
|-- CCM_Local
| |-- Console.h
| `-- Makefile.py
|-- CCM_Local_CCM_Session_Hello
| |-- HelloHome_gen.cc
| |-- HelloHome_gen.h
| |-- Hello_gen.cc
| |-- Hello_gen.h
| `-- Makefile.py
|-- CCM_Local_CCM_Session_Hello_mirror
| |-- HelloHome_mirror_gen.cc
| |-- HelloHome_mirror_gen.h
| |-- Hello_mirror_gen.cc
| |-- Hello_mirror_gen.h
| `-- Makefile.py
|-- CCM_Local_CCM_Session_Hello_mirror_share
| |-- HelloHome_mirror_share.h
| |-- Hello_mirror_share.h
| `-- Makefile.py
|-- CCM_Local_CCM_Session_Hello_share
| |-- HelloHome_share.h
| |-- Hello_share.h
| `-- Makefile.py
|-- CCM_Test
| |-- Makefile.py
| `-- _check_CCM_Local_CCM_Session_Hello.cc
|-- confix.conf
|-- idl3
| |-- Console.idl3mirror
| |-- Hello.idl3mirror
| `-- HelloHome.idl3mirror
`-- src
|-- HelloHome_app.cc
|-- HelloHome_app.h
|-- HelloHome_entry.h
|-- HelloHome_mirror_app.cc
|-- HelloHome_mirror_app.h
|-- HelloHome_mirror_entry.h
|-- Hello_app.cc
|-- Hello_app.h
|-- Hello_mirror_app.cc
|-- Hello_mirror_app.h
`-- Makefile.py
# Now we use the existing business logic from test/CppGenerator/facet
> cp -r ../../CppGenerator/facet/src hello/
> cd hello/
> confix.py --profile="ccmtools" --configfile="confix.conf" \
--bootstrap --configure --mak--targets="all check"
=> ... => All 1 tests passed
# Note that we can also use the ccmtools-c++-configure and ccmtools-c++-make
# to build the component...
After that (and the test/idl/facet_basic_types) example, I checked in the
changes.
:-) Egon
|
|
From: Leif J. <le...@am...> - 2003-10-12 19:30:24
|
Word up -
On Sun, 12 Oct 2003, Egon Teiniker wrote:
> Hey Leif!
>
> Quoting Leif Johnson <le...@am...>:
> > > My question to you is, how extensive these changes will be in the
> > > CppLocalGenerator (two more <<<<<SPLIT>>>>> sections in the MHomeD=
ef
> > > and MComponentDef Templates and changes in the writeOutput() metho=
d)?
> > > Thus, what I need are the empty *_share.h and *EntryPoint.h files,=
I
> > > can fill the templates from the example by myself.
> >
> > This change was easy to make ... much easier than the Python wrapper
> > generator is turning out to be. :-/ See the attached patch for the
> > changes ; I'm going to go ahead and check it in now so you can fill =
in
> > the MHomeDef and MComponentDef templates at your leisure.
>
> Wow, that was really fast!
Well, it's noon here. And I'm a coding fool, yo. Isn't it getting late
over there ? :)
> > Can we remove the file copying stuff from the ccmtools-c++-* scripts=
?
>
> Well, with the new directory structure, we only need the
> ccmtools-c++-generate script and some confix calls (for configure,
> make, install).
Hmm. Can you go ahead and change this for me ? I'm not sure how it needs
to be done.
> > How will this change the test/CppGenerator/test-loader.sh script, an=
d
> > the tests in that directory ?
>
> Uff, you are right! The test-loader.sh must also be changed to handle
> this new component structure. The test code in the
> ccmtools/test/CppGenerator/* directories could be stored in the same
> src and CCM_Test sub-directories. To run the test, these
> sub-directories are copied to the sandbox directory. After that, the
> component can be build and checked in a single confix call - that's
> the vision ;-)
It sounds like we can just do :
cp -r test/CppGenerator/${test_name}/* \
test/CppGenerator/sandbox/${test_name}
Assuming that test/CppGenerator/${test_name} contains src/ and CCM_Test/
subdirectories, which contain the appropriate test code. Is that right ?
> What do you think about this changes?
They seem good to me, particularly the entry point stuff. C++ name
mangling is particularly nasty voodoo, so with the entry point headers
our generated components will be much easier to access from other
libraries.
I'm not sure yet about the rest, need to see what goes in the _share.h
and _gen.h files. I'm sure, though, that if you and J=C3=B6rg talked it =
over,
then it will work out pretty well.
leif
--
Leif Morgan Johnson : http://ambient.2y.net/leif/
|
|
From: Teiniker E. <ego...@tu...> - 2003-10-12 19:11:42
|
Hey Leif!
Quoting Leif Johnson <le...@am...>:
> > My question to you is, how extensive these changes will be in the
> > CppLocalGenerator (two more <<<<<SPLIT>>>>> sections in the MHomeDef
> > and MComponentDef Templates and changes in the writeOutput() method)?
> > Thus, what I need are the empty *_share.h and *EntryPoint.h files, I
> > can fill the templates from the example by myself.
>
> This change was easy to make ... much easier than the Python wrapper
> generator is turning out to be. :-/ See the attached patch for the
> changes ; I'm going to go ahead and check it in now so you can fill in
> the MHomeDef and MComponentDef templates at your leisure.
Wow, that was really fast!
> Also, I named the entry point file %(Identifier)s_entry.h just to keep
> with the name_purpose.{cc|h} convention.
Yes, that's a good idea.
> > As you know, the ccmtools-c++-configure and ccmtools-c++-make scripts
> > copy the *_app.* files into the generated package. This causes some
> > problems:
> > *) It's not possible to configure and make the component with a single
> > confix call.
> > *) If we use more than the generated *_app.* files, we have to copy
> > these files manually into the package directory.
>
> Can we remove the file copying stuff from the ccmtools-c++-* scripts ?
Well, with the new directory structure, we only need the ccmtools-c++-generate
script and some confix calls (for configure, make, install).
> How will this change the test/CppGenerator/test-loader.sh script, and
> the tests in that directory ?
Uff, you are right!
The test-loader.sh must also be changed to handle this new component structure.
The test code in the ccmtools/test/CppGenerator/* directories could be stored in
the same src and CCM_Test sub-directories. To run the test, these
sub-directories are copied to the sandbox directory. After that, the component
can be build and checked in a single confix call - that's the vision ;-)
What do you think about this changes?
:-) Egon
|
|
From: Leif J. <le...@am...> - 2003-10-12 18:46:56
|
Hi Egon -
> My question to you is, how extensive these changes will be in the
> CppLocalGenerator (two more <<<<<SPLIT>>>>> sections in the MHomeDef
> and MComponentDef Templates and changes in the writeOutput() method)?
> Thus, what I need are the empty *_share.h and *EntryPoint.h files, I
> can fill the templates from the example by myself.
This change was easy to make ... much easier than the Python wrapper
generator is turning out to be. :-/ See the attached patch for the
changes ; I'm going to go ahead and check it in now so you can fill in
the MHomeDef and MComponentDef templates at your leisure.
Also, I named the entry point file %(Identifier)s_entry.h just to keep
with the name_purpose.{cc|h} convention.
> As you know, the ccmtools-c++-configure and ccmtools-c++-make scripts
> copy the *_app.* files into the generated package. This causes some
> problems:
> *) It's not possible to configure and make the component with a single
> confix call.
> *) If we use more than the generated *_app.* files, we have to copy
> these files manually into the package directory.
Can we remove the file copying stuff from the ccmtools-c++-* scripts ?
How will this change the test/CppGenerator/test-loader.sh script, and
the tests in that directory ?
leif
--
Leif Morgan Johnson : http://ambient.2y.net/leif/
|
|
From: Teiniker E. <ego...@tu...> - 2003-10-12 17:40:30
|
Hey Leif!
As you know, the ccmtools-c++-configure and ccmtools-c++-make scripts copy t=
he
*_app.* files into the generated package.
This causes some problems:
*) It's not possible to configure and make the component with a single confi=
x
call.
*) If we use more than the generated *_app.* files, we have to copy these fi=
les
manually into the package directory.
After a discussion with J=F6rg, I realized the facet example with the follow=
ing
directory structure:
facet/
|
+-- Hello.idl
+-- confix.conf
+-- CCM_Local
+-- CCM_Local_CCM_Session_Hello
+-- CCM_Test
|
+-- CCM_Local_CCM_Session_Hello_share
| |
| +-- HelloHome_share.h
| +-- Hello_share.h
| +-- Makefile.py
+-- src
|
+-- HelloEntryPoint.h
+-- HelloHome_app.h
+-- HelloHome_app.cc
+-- Hello_app.h
+-- Hello_app.cc
+-- Makefile.py
There is no explicit package directory, and the application code is stored i=
n
the parallel src directory. The additional CCM_Local_CCM_Session_Hello_share
directory contains a header file for home and the component (this is necessa=
ry
to avoid cyclic includes). The *_share.h files contain a subset of the *_gen=
.*
source code.
Using this directory structure, we can build the whole component in a single
confix call - without any file copy.
Note the HelloEntryPoint.h file, it contains the
extern "C" localComponent::HomeExecutorBase* create_HelloHome();
declartaion. This is the only dependency between the generated and the
application code.
My question to you is, how extensive these changes will be in the
CppLocalGenerator (two more <<<<<SPLIT>>>>> sections in the MHomeDef and
MComponentDef Templates and changes in the writeOutput() method)?
Thus, what I need are the empty *_share.h and *EntryPoint.h files, I can fil=
l
the templates from the example by myself.
:-) Egon
|
