[Gtk-sharp-list] Tinymail DotNet bindings update

[Philip Van Hoof]

Hi there,

If I look at the prefix of both gtk-sharp and tinymail's -sharp
installation, I noticed that gtk-sharp has .config files installed.

Tinymail's -sharp install directory doesn't have these .config files
installed. I'm not really immediately finding what in the build of
gtk-sharp is installing them (I kept the Makefile.include identical for
that part of the build Makefile code afaik).

I'm guessing these config files are necessary for the .dll->.so mapping?
Something like that is what they seem to contain as XML data. Obviously
I mimicked them as good as possible using gtk-sharp's code.

Also, what is this policy.$(API_VERSION).config file for by the way?


On Wed, 2008-01-30 at 10:55 +0100, Philip Van Hoof wrote:
> Hi there,
> 
> I just committed the DotNet bindings for Tinymail. People who've been
> watching Tinymail's trunk might have noticed that I this this yesterday
> and the day before already.
> 
> Today I completely restructured it, though. I made it more or less the
> same as how gtk-sharp itself is structured. This means that each
> separate library has its own subdirectory and the Makefile.am includes a
> toplevel Makefile.include.
> 
> I even copied that Makefile.include from gtk-sharp's toplevel directory
> and adapted it (once Gapi is installed, it's not necessary to put the
> runtime's executable in front of it, and I had to adjust a few minor
> other things too)
> 
> You can find the bindings here:
> 
> https://svn.tinymail.org/svn/tinymail/trunk/bindings/dotnet/
> 
> 
> They might not be 100% correct. I tried hard to get everything right
> immediately but I'm guessing it's not right yet.
> 
> For example the libtinymail-platform-sharp for some reason only has
> one .cs file in generated. That can't be right. Most of the types that
> in the C API only have a constructor also didn't get a .cs file in the
> generated directory. If I look at the generated API, a lot is missing.
> 
> I have no clue why the codegenerator of gapi is not generating code for
> those types. They do seem to be in the -api.xml and .raw files and they
> are not slashed in the .metadata files.
> 
> The libtinymail-camel-sharp things seem to crash gapi's code generator,
> so this one is not in the SUBDIRS of bindings/dotnet/Makefile.am a.t.m.
> 
> I'm generating .pc files for the pkgconfig libdir, but they might not be
> completely correct. I tried mimicking gtk-sharp's files but I might have
> gotten something wrong. I don't know (haven't testing it yet).
> 
> The SNK file, the AssemblyInfo.cs file, are all things that I might have
> gotten wrong too. I tried copying as much as possible from how gtk-sharp
> does all this magic.
> 
> I have not yet made .custom files for Tny.List and Tny.Stream. The
> reason is that both are GTypeInterface types (interfaces in .NET) and
> that adding code in the .custom file only alters the interface. It wont
> alter the Adaptor that Gapi generates. So I can't really influence these
> interfaces a lot (I can't make them require implementing IList, for
> example).
> 
> For Tny.Stream I might have to rename the original Tny.Stream to
> something else in the .NET binding and make the .NET version of
> Tny.Stream inherit from System.IO.Stream. This, is going to be quite
> tricky to get it right, I think.
> 
> I can really use assistance from the gurus in this channel. Tinymail is
> a relatively large library (in terms of API availability) with more
> compilation options, possibilities, combinations and switches than Gtk+
> has. That's because the project's focus is mobiles and each and every
> mobile is typically different from each other mobile.
> 
> 
> Anyway .. so here's the skeleton of the binding. All the unpleasant
> crappy autotools work is done.
> 
> The tweaking of it is something I'm sure a .NET enthusiast is going to
> like working on.
> 
> https://svn.tinymail.org/svn/tinymail/trunk/bindings/dotnet/
> 
> 
-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be