Re: [ccmtools-devel] Local and remote tests

[Teiniker E. <ego...@tu...>]

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
>