Browse thread
[Caml-list] Ocamlmakefile and Lablgtk
-
Johann Spies
-
Markus Mottl
-
Johann Spies
-
Markus Mottl
-
Florian Hars
-
Markus Mottl
- Jacques Garrigue
- Johann Spies
-
Markus Mottl
-
Florian Hars
-
Markus Mottl
-
Johann Spies
-
Markus Mottl
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jacques Garrigue <garrigue@k...> |
| Subject: | Re: [Caml-list] Ocamlmakefile and Lablgtk |
From: Markus Mottl <markus@oefai.at> > Florian Hars schrieb am Dienstag, den 13. November 2001: > > lablgtk comes as a library file, the problem is that every program that > > uses the library must properly initialize it before it can use it. > > gtkInit does just this: > [snip] > > But why not just link the module in the right order with the rest of > the library? Then things will be initialized as required. Or are there > circumstances where you don't want initialization? This is exactly the reason. Take for instance Unison. It is linked with lablgtk, but does not want to initialize GTK+ when used in text mode. This is very important, otherwise you would need an X-server running everytime you start Unison. While Unison was the original reason, I think it is indeed good practice to initialize by hand, without linking gtkInit.cmo. Then you know explicitely what is called and when. This avoids difficulties with debugging. Note also that in a real application there are things you want to do immediately after the initialization (or even before), and this is hard to do if you don't know where it occurs. On the other hand, if you forget to initialize, you will get a few dozen warnings, so this should not be too difficult to detect. So the rule of the thumb is: use gtkInit.cmo if you are developping with the toplevel and all your program is included in one file, but switch to explicit initialization as soon as it gets bigger. This way, OCamlMakefile should not be a problem :-) Jacques Garrigue ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr