This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: shared object of CDL.
>>>>> "Masato" == Masato Taruishi <taru@debian.org> writes:
Masato> At Sun, 11 Aug 2002 18:52:33 +0100 (BST),
Masato> 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.
Masato> Cool. Cdlsh can access eCos database directly from shell
Masato> programs. It provide more flexibility.
Masato> But from the point of extended modules' view, in the way
Masato> to use cdlsh, I guess we must need to implement all
Masato> methods if we provide the same class structures as C++. In
Masato> the way to use a shared library, we can achive it by only
Masato> creating wrapper to libcdl. This can be auto-generated by
Masato> using swig (http://www.swig.org/) etc, or at least it
Masato> makes easy to maintain. So we need both of them.
I am not sure that using swig, i.e. automatically generating a Tcl or
Python API based on the C++ ones, is the best way forward. The C++ API
is mostly appropriate for C++ code (although I would really like to
make some of the naming more consistent one day). For scripting I
think I would want a somewhat different interface, generally operating
at a higher-level (although most of the underlying C++ functionality
should still be accessible). As an example, IIRC swig does not cope
with C++ data types like std::vector<>. Where there is a C++ function
const std::vector<CdlNode>& CdlContainerBody::get_contents() const
the Tcl API would look something like:
cdl_info children $component
where $component would be a string like CYGPKG_KERNEL. It would return
a Tcl list of the names of the child nodes. Not a pointer in sight
anywhere.
Much of this would be straightforward. The really tricky bits to map
on to a Tcl API are the transaction and inference engine support.
<snip>
Masato> OK, I understand your worry about compatibility. The patch
Masato> shouldn't be merge into main-trunk until we really know
Masato> that the change doen't break anything.
Masato> If we know the patch doesn't break anything, do you add it
Masato> into main-trunk?
Yes, once I am sure that the patch doesn't break anything - especially
for people who develop under Windows.
Bart
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss