Menu
▾
▴
ccmtools-devel
|
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
|
|
From: Leif J. <le...@am...> - 2003-10-12 18:46:56
Attachments:
share.patch
|
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 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 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/
|
Thanks for helping keep SourceForge clean.
X