Re: [ECOS] shared object of CDL.

[Masato Taruishi <taru at debian dot org>]

At Sun, 11 Aug 2002 18:52:33 +0100 (BST),
Bart Veer wrote:

> If we are going to move towards Python modules, dynamically loadable
> Tcl extensions, or anything like that then moving to libtool is the
> only sensible way forward. My own plans along those lines involved
> extending the ecosconfig command with a new sub-command cdlsh, thus
> providing a Tcl interpreter plus commands like cdl_get, cdl_set,
> cdl_database, ... That could be achieved without dynamic loading
> or shared libraries. And it would not happen for a while yet, there
> are other things I am working on.

Cool. Cdlsh can access eCos database directly from shell programs. It
provide more flexibility.

But from the point of extended modules' view,
in the way to use cdlsh, I guess we must need to implement all methods
if we provide the same class structures as C++. In the way to use a shared
library, we can achive it by only creating wrapper to libcdl. This can
be auto-generated by using swig (http://www.swig.org/) etc, or at least
it makes easy to maintain. So we need both of them.

> Before we can make a switch to libtool, we need to be sure that we are
> not going to break things for other users. Currently I can do test
> builds under Linux and under Windows 98 with current net cygwin. I
> would also want somebody to do testing on at least one other version
> of Unix, e.g. Solaris. Also, it is important for now that we do not
> break builds with Visual C++ since the current Windows GUI configtool
> cannot be built under cygwin - and this is where there are likely to
> be problems. I do not have a Visual C++ installation at present.
> 
> Are there any volunteers willing to:
> 
>   a) do some test builds on Unix systems other than Linux.
> 
>   b) do builds with Visual C++, and help to resolve any problems.
>      Experience with autoconf/automake/libtool would be a big help.
> 
> I have some changes to the configury of my own which I want to check
> in. These are mostly clean-ups and some reorganization, so hopefully I
> have not broken anything for platforms I cannot test, but again it
> would be useful to have some volunteers who can help with the testing.

OK, I understand your worry about compatibility. The patch shouldn't be
merge into main-trunk until we really know that the change doen't break
anything.

If we know the patch doesn't break anything, do you add it into main-trunk?

Thanks
---
Debian Project http://debian.org/ - Masato Taruishi <taru@debian.org>

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss