Re: [Crystal-develop] C# bindings using the bindingsplit branch.

[Pablo M. <ca...@si...>]

Hi!

sorry, but i messed up the corepost.i files for java and perl. im not
sure adding all the post stuff there will help, otherwise we can use
something like what you propose.

the idea is <lang>post files dont exist anymore, and they should be
split to their correct <module>post.i files, still, i believe it should
work as is now in the branch. there should be no duplication of
directives in any .i files, the one you seen was a mess up on my side,
sorry.

 Pablo

Ronie Salgado wrote:
> The bindings split cspace.i is not compatible with the trunk cspace.i,
> because it doesn't include the file bindings/<insert language
> name>/<insert language name>post.i . For example it doesn't include
> the file bindings/java/javapost.i, which results with the no
> generation of some java code, like the event handler. Looking at the
> perl module i have seen that the file bindings/perl/perlpost.i is
> equal to the file bindings/perl/perlcore.i, which may result in
> duplicated code if the first file were included if you use the
> monolithic approach. My bindings doesn't build out of the box because
> the above problem.
>
> Here I'm attaching a patch with my bindings using the monolithic, and
> a very simple fix to the above problem.
>
> The fix works adding a simple macro in the file
> bindings/common/basepost.i and invoking it at the end of the file
> bindings/cspace.i
>
> If you want to test my bindings you must run the configure script with
> the --with-csharp argument which enable the csharp bindings
> generation. The bindings produce the file libcspacesharp.so and
> crystalspace-sharp.dll . The bindings only can be built with mono
> (maybe with Portable.Net). Micro$oft C# compiler don't work because it
> can't find a file (a bug?). You can compile the bindings under MSYS
> using mono. I haven't tested it under cygwin, but if you use mono and
> the nant provided by mono it should work.
>
> At this moment the bindings use the monolithic approach, but i will
> adjust it for use the split approach.
>
> greetings.
>
> Ronie.
>
> 2007/9/21, Pablo Martin < ca...@si...
> <mailto:ca...@si...>>:
>
>     The bindingsplit branch allows both monolithic and split approach.
>     The
>     idea is that languages that can be adapted will generate several
>     modules
>     thus benefiting from less memory usage when compiling and other
>     goodies
>     (like being able to link on linux-ppc). The idea with allowing to
>     still
>     build monolithic approach is to make the transition soft and allow
>     time
>     for java and perl to adapt when the need arises.
>
>     If you want to go for the split approach (which i recommend), the
>     modules are defined by the .i files in include/bindings/ dir (except
>     scf.i which should probably be moved to common/ and cspace.i which is
>     the entry point for monolithic bindings).
>
>     Also, if you already have something working it would be neat if you
>     could test as is with the bindingsplit codebase to see if it directly
>     works (in theory the bindingsplit cspace.i should be compatible with
>     trunk cspace.i (ie, if you substitute the include/bindings dir in
>     trunk
>     with the include/bindings dir in bindingsplit branch everything
>     should
>     still work), but i still need reports from other languages to
>     verify this).
>
>     greetings
>
>     Pablo
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Crystal-develop mailing list
> Cry...@li...
> https://lists.sourceforge.net/lists/listinfo/crystal-develop
>