Message-ID: <436866C8.9070505 at rftp.com>
Date: Tue, 01 Nov 2005 23:12:08 -0800
From: Robert Roessler <robertr at rftp.com>
Organization: Robert's High-performance Software
MIME-Version: 1.0
To: Jacques Garrigue <garrigue at math.nagoya-u.ac.jp>
CC: lablgtk at math.nagoya-u.ac.jp
Subject: Re: Alternatives to Val_GtkObject_sink?
References: <43683CF3.8070407 at rftp.com> <20051102.143553.258141660.garrigue at math.nagoya-u.ac.jp>
In-Reply-To: <20051102.143553.258141660.garrigue at math.nagoya-u.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Jacques Garrigue wrote:
> Dear Robert,
> 
>> Val_GtkObject_sink seems to be the correct way to "wrap" or "register" 
>> a pointer to a newly instantiated [C-based] widget... as this function 
>> now has been effectively "un-exported" from dlllablgtk2.dll in the 
>> Windows binary distribution of LablGTK, what are the available (and 
>> recommended) options to anyone trying to interface C-written widgets 
>> (as most of them are) to LablGTK?
> 
> Well, in fact this is not the case: it is exported.

This is why I used the modifier "effectively"... I know that it is 
exported, as you originally (and generously) did the work to export 
some of the infrastructure primitives from dlllablgtk2.dll after I 
pointed out the need and requested it back in June! ;)

> Or are you talking about the absence of dlllablgtk2.lib?
> You're perfectly free to build it yourself and distribute it with your
> library... It's not even difficult to do, once you've got the required
> Gtk headers, which you will need anyway to compile a Gtk extension.

This *can* be done - but why duplicate this file which is *always* 
created when you perform a Windows build for a given release of 
LablGTK?  The duplication runs the risk of not being "in synch" with 
the canonical version of the export library.  It is sort of like 
violating a normalization form in the database world. :)

> And in any case, this won't affect your end users.
> Or could you explain to me in which situation the problem appears
> (i.e. you need dlllablgtk2.lib, but don't compile any Gtk C code?)
> Then we could discuss this addition (not hard to do!)

It depends what you mean by "compile any Gtk C code" - but I am 
discussing the same situation I was yesterday (which I encountered 
myself as soon as I tried to rebuild my widget wrapper and link it 
with your new release of LablGTK): I have a single "ml_scintilla" C 
wrapper file which wraps a widget "new" call.

It does this in the [trivial] function:

CAMLprim value ml_sci_new(value unit)
{
	GtkWidget* scintilla_widget = scintilla_new();
	return Val_GtkWidget_sink(scintilla_widget);
}

Some of my included headers:

#include <gtk/gtk.h>

#include <caml/memory.h>
#include <caml/alloc.h>
#include <caml/fail.h>

#include <wrappers.h>
#include <ml_gtk.h>
#include <ml_gobject.h>

Here is my perceived "problem" with a LablGTK [Windows] distribution 
which does not include the "dlllablgtk2.lib" export lib: apart from 
any issues of supposed "sophistication" of Windows users, I believe 
that we can safely say that users (*and* programmers) on Windows 
systems are much less used to [re]building the tools that they use in 
their work on Windows - because these tools usually come to them as 
pre-built binaries.

OCaml Windows users (because of picking a cool language like OCaml) 
are likely a bit more comfortable with typing the occasional make 
command... but still without necessarily being people who would dream 
of building their own kernels - or something as complex as OCaml 
itself - or even LablGTK. ;)

It is this group of users/programmers that I think I (or anyone else 
producing Windows binaries of OCaml libraries/components) am 
targeting: they may choose to initially use the supplied binaries (or 
not), but they may very well [eventually] decide to do that "make" (or 
"ocaml build.ml") - and they expect it to work!

These "consumers" of our software may not even know C/C++ - nor should 
they need to. :)  But we should be making their lives easier rather 
than raising barriers.  Now I expect that you will next say "But what 
about that #include <gtk/gtk.h>"?

And like a lawyer (or sophist?) I will make two contradictory answers:

1) not my (our) problem :)

2) we (the LablGTK community) *could*, like your choosing to ship the 
GTK libs, could gather together and ship an archive which included the 
GTK headers, or at least a tree that supported the kinds of builds 
that our makefiles expect

In my case, I have just (like I expect a lot of other have) 
interpreted the instructions from Tor Lillqvist and built up my own 
GTK include tree - why not make something like it available in a 
single download, as you have done with the lib dependencies?

Then I (or any other builder of LablGTK wrappers and tools) can just say:

download the LablGTK binary distribution, along with the 
"dependencies" packages, and install them (including your "ocaml 
build.ml")

download the XYZ LablGTK OCaml binding/wrapper and install it ("make" 
or "ocaml build.ml" or whatever)

Voilą - happy users/programmers who can produce other cool 
applications and tools using OCaml and LablGTK!

Or you could just add the export lib to the binary distribution and be 
done with it... ;)

BTW, since I don't understand the exact situation with import 
libraries in the *nix world (which is why I keep asking for help with 
my LablPCRE, LablScintilla, and RCaml makefiles), I will ask now: it 
looks like non-Windows users will be in the same boat vis-ą-vis import 
libs (but without the pre-built binaries).  If this is true, then I 
certainly mean to include consideration of their situation in any 
eventual resolution at which we may arrive!

Robert Roessler
robertr@rftp.com
http://www.rftp.com