Re: [ECOS] shared object of CDL.

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "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