Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Caml-list] Ocamlmakefile and Lablgtk

74 views
Skip to first unread message

Johann Spies

unread,
Nov 12, 2001, 1:31:54 PM11/12/01
to caml...@inria.fr
am trying to figure out how to use Ocamlmakefile to compile
lablgtk programs.

With the following Makefile:

--------------------------------------------------------
OCAMLMAKEFILE=/usr/share/ocaml-tools/OcamlMakefile
SOURCES=calc.ml
RESULT=calc
LIBS=lablgtk gtkInit
INCDIRS=+lablgtk
OCAMLFLAGS=-labels
include $(OCAMLMAKEFILE)
----------------------------------------------------------

I get :
----------------------------------------------------------
js-19:07:58-/tmp$make
make[1]: Entering directory `/tmp'
ocamlc -I +lablgtk lablgtk.cma gtkInit.cma -o calc \
calc.cmo
Cannot find file gtkInit.cma
make[1]: *** [calc] Error 2
make[1]: Leaving directory `/tmp'
make: *** [byte-code] Error 2

js-19:07:59-/tmp$make nc
make[1]: Entering directory `/tmp'
ocamlopt -I +lablgtk
lablgtk.cmxa gtkInit.cmxa -o calc \
calc.cmx
Cannot find file gtkInit.cmxa
make[1]: *** [calc] Error 2
make[1]: Leaving directory `/tmp'
make: *** [native-code]
Error 2
-----------------------------------------------------------
How do I inform the compiler through Ocamlmakefile to use options
gtkInit.cmx as in

ocamlopt -I +lablgtk -labels -o testgtk.opt lablgtk.cmxa gtkInit.cmx
testgtk.ml ?

Regards.
Johann

--
Johann Spies Telefoon: 021-808 4036
Informasietegnologie, Universiteit van Stellenbosch

"He that loveth father of mother more than me is not
worthy of me; and he that loveth son or daughter more
than me is not worthy of me. And he that taketh not
his cross, and followeth after me, is not worthy of
me." Matthew 10:37,38
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.inria.fr

Markus Mottl

unread,
Nov 12, 2001, 1:46:49 PM11/12/01
to Johann Spies, caml...@inria.fr
On Mon, 12 Nov 2001, Johann Spies wrote:
> --------------------------------------------------------
> OCAMLMAKEFILE=/usr/share/ocaml-tools/OcamlMakefile
> SOURCES=calc.ml
> RESULT=calc
> LIBS=lablgtk gtkInit
> INCDIRS=+lablgtk
> OCAMLFLAGS=-labels
> include $(OCAMLMAKEFILE)
> ----------------------------------------------------------
[snip]

> How do I inform the compiler through Ocamlmakefile to use options
> gtkInit.cmx as in

I assume the problem is that you haven't specified where to find
libraries. Note that INCDIRS is only for interface files (.cmi), whereas
LIBDIRS is necessary if there are libraries in the directory against
which you want to link. Therefore, add this line:

LIBDIRS=+lablgtk

Hope that helps!

Regards,
Markus Mottl

--
Markus Mottl mar...@oefai.at
Austrian Research Institute
for Artificial Intelligence http://www.oefai.at/~markus

Johann Spies

unread,
Nov 12, 2001, 6:11:14 PM11/12/01
to caml...@inria.fr
On Mon, Nov 12, 2001 at 06:59:39PM +0100, Markus Mottl wrote:
> > gtkInit.cmx as in
>
> I assume the problem is that you haven't specified where to find
> libraries. Note that INCDIRS is only for interface files (.cmi), whereas
> LIBDIRS is necessary if there are libraries in the directory against
> which you want to link. Therefore, add this line:
>
> LIBDIRS=+lablgtk

Thanks for the suggestion. I have added this line, but it makes
no difference:
js-23:25:58-~/ocaml/lablgtk$make nc
make[1]: Entering directory `/home/js/ocaml/lablgtk'
ocamlopt -c -labels -w s -I +lablgtk calc.ml
ocamlopt -I +lablgtk -ccopt -L+lablgtk lablgtk.cmxa
unix.cmxa gtkInit.cmxa -o calc \


calc.cmx
Cannot find file gtkInit.cmxa

^^^^^^^^^^^^
The problem is that it should use gtkInit.cmx. There is no
gtkInit.cmxa (at least in thei Debian distribution).

After your message I went back and read the documentation on the
compiler again. I then tried to put
/usr/lib/ocaml/lablgtk/gtkInit.cmx on the SOURCES line and it
worked in some cases, but I suspect it is not the correct way to
do it. I did not previously understand the difference between
.cmx and .cmxa files. It becomes clearer now.

However the problem is not solved yet.

The following Makefile compiles (make nc) without complaints:


OCAMLMAKEFILE=/usr/share/ocaml-tools/OcamlMakefile
SOURCES=testgtk.ml /usr/lib/ocam/lablgtk/gtkInit.cmx
RESULT=testgtk
LIBS=lablgtk
INCDIRS=+lablgtk
LIBDIRS=+lablgtk
OCAMLFLAGS=-labels -w s
include $(OCAMLMAKEFILE)

As I understand it, it should be the equivalent of

ocamlopt.opt -w s -I +lablgtk -labels -o testgtk\
lablgtk.cmxa gtkInit.cmx testgtk.ml

But the latter produces a binary which runs without a problem
and the first (make nc) produces a binary of a different size
with a lot of error messages.

Johann.
--
J.H. Spies - Tel. 021-982 2694 / 082 782 0336 / 021-808 4036(w)
Posbus 4668, Tygervallei 7536
"And we know that all things work together for good to
them that love God, to them who are the called
according to his purpose."
Romans 8:28

Markus Mottl

unread,
Nov 13, 2001, 3:03:59 AM11/13/01
to Johann Spies, caml...@inria.fr
On Tue, 13 Nov 2001, Johann Spies wrote:
> Cannot find file gtkInit.cmxa
> ^^^^^^^^^^^^
> The problem is that it should use gtkInit.cmx. There is no
> gtkInit.cmxa (at least in thei Debian distribution).

Ok, I see, I thought that we were talking about a library. Try the
following instead:

OCAMLNLDFLAGS := gtkInit.cmx
OCAMLBLDFLAGS := gtkInit.cmo

It would certainly be better to have a true library file in the
distribution rather than the "naked" compiled module file.

> I did not previously understand the difference between .cmx and
> .cmxa files. It becomes clearer now.

.cmx-files are (natively) compiled implementations of OCaml-modules,
.cmxa-files combine several such implementations, i.e. they are library
files.

Regards,
Markus Mottl

--
Markus Mottl mar...@oefai.at
Austrian Research Institute
for Artificial Intelligence http://www.oefai.at/~markus

Florian Hars

unread,
Nov 13, 2001, 3:56:45 AM11/13/01
to Markus Mottl, Johann Spies, caml...@inria.fr
On Tue, Nov 13, 2001 at 12:40:47AM +0100, Markus Mottl wrote:
> It would certainly be better to have a true library file in the
> distribution rather than the "naked" compiled module file.

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:

(* $Id: gtkInit.ml,v 1.2 2000/03/02 08:13:15 garrigue Exp $ *)

(* Does the initialization for toplevels *)

let locale = GtkMain.Main.init ()

And that's all it does. You could do away with this file by calling
GtkMain.Main,init () in your own application.

Yours, Florian.

Markus Mottl

unread,
Nov 14, 2001, 8:26:18 AM11/14/01
to Florian Hars, Johann Spies, caml...@inria.fr
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?

Regards,
Markus Mottl

--
Markus Mottl mar...@oefai.at
Austrian Research Institute
for Artificial Intelligence http://www.oefai.at/~markus

Johann Spies

unread,
Nov 14, 2001, 8:26:44 AM11/14/01
to caml...@inria.fr
Thanks Florian and Markus.

You have helped me a lot.

Regards.

Johann.


--
Johann Spies Telefoon: 021-808 4036
Informasietegnologie, Universiteit van Stellenbosch

"He that findeth his life shall lose it; and he that
loseth his life for my sake shall find it."
Matthew 10:39

Jacques Garrigue

unread,
Nov 14, 2001, 9:11:56 AM11/14/01
to mar...@oefai.at, caml...@inria.fr
From: Markus Mottl <mar...@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

Markus Mottl

unread,
Nov 14, 2001, 9:24:30 AM11/14/01
to Jacques Garrigue, caml...@inria.fr
On Wed, 14 Nov 2001, Jacques Garrigue wrote:
> From: Markus Mottl <mar...@oefai.at>

> > 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.

Ok, I see, I didn't know what kind of initializations have to be
performed.

> While Unison was the original reason, I think it is indeed good
> practice to initialize by hand, without linking gtkInit.cmo.

I agree.

> 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 :-)

OCamlMakefile respects the order of files as defined by the user to
exactly avoid this problem of initialization order in the presence of
side effects. So blaming OCamlMakefile for wrong linking order is not
an excuse :-)

Regards,
Markus Mottl

--
Markus Mottl mar...@oefai.at
Austrian Research Institute
for Artificial Intelligence http://www.oefai.at/~markus

0 new messages