[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-swt-dev] Re: Fw: Re: [Swig-dev] SWIG for Java
|
>Therefore, we will first have to ask the SWT people if they could
consider using GCC
>instead of VS.NET; or at least keep it compatible somehow. In terms of
the process
>of running after the SWT people and updating CNI wrappers as they bring
out new
>releases of SWT, we could ask them if they can facilitate our effort and
take GCC
>into account.
It is quite unlikely that we will move from VS to GCC for compiling our
JNI c code on Windows.
Please enter a bug report against SWT with a list of the things which
currently are not compatible with GCC and we will try to facilite your
effort.
Erik Poupaert <erik.poupaert@xxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
07/14/2003 09:21 AM
Please respond to platform-swt-dev
To: Erik Poupaert <erik.poupaert@xxxxxxxxx>
cc: tromey@xxxxxxxxxx, platform-swt-dev@xxxxxxxxxxx
Subject: [platform-swt-dev] Re: Fw: Re: [Swig-dev] SWIG for
Java
> There is the %ignore SWIG directive which makes it possible to ignore
particular
> C/C++ functions so you probably won't need to generate this layer of
wrappers by
> hand. The %rename directive will wrap a C++ function with a different
Java proxy
> function name. Also %extend will add in methods not in the C++ class.
These
> directives exist to give large flexibility to the way the C++ code is
wrapped
> without having to modify existing code or headers.
I understand that all the problems I've mentioned have been thought of
already! I
am definitely going to read up these facilities.
By the way, we wouldn't be able to modify existing C/C++ code anyway
(win32api). We
can modify SWT to some extent (but long-term untenably).
Fortunately, few of the C/C++ projects I am interested in, use templates
and other
really deadly constructs. I just hope that the GCJ won't find the
resources to
introduce them in Java either :-)
Both SWT and win32 are moving targets. SWT, as it is now compiled with
VS.NET by
default, introduces new win32 APIs regularly that the mingw people have
not yet been
able to support; which means that the win32api facilities for GCC have to
be updated
first. Only then, we can start wrapping them.
Therefore, we will first have to ask the SWT people if they could consider
using GCC
instead of VS.NET; or at least keep it compatible somehow. In terms of the
process
of running after the SWT people and updating CNI wrappers as they bring
out new
releases of SWT, we could ask them if they can facilitate our effort and
take GCC
into account.
--
http://www.freestyler-toolkit.org absolutely unique
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev