Can you install lablgl with ocaml 5.3?

Ecosystem
,
1

Hello

I am a bit lost.

$ opam install lablgl
The following actions will be performed:
=== remove 2 packages
  ⊘ base-effects        base           [conflicts with ocaml]
  ⊘ ocaml-compiler      5.3.0
=== downgrade 2 packages
  ↘ ocaml               5.3.0 to 5.1.1 [required by lablgl]
  ↘ ocaml-base-compiler 5.3.0 to 5.1.1 [required by ocaml]

However opam show lablgl gives me

depends      "ocaml" {>= "4.14"}
             "ocamlfind" {>= "1.2.1"}
             "camlp-streams" {build}
             "camlp5"
             "conf-libgl"
             "conf-libglu"
             "conf-freeglut"

and I am able to install manually all these packages. Still, after this, the same downgrade message as above shows up when opam install lablgl. How is this possible? I don’t understand the logic.

2

oh I see, it’s because camlp5 has

conflicts    "ocaml-option-bytecode-only"
             "pa_ppx" {<= "0.19"}
             "p5scm" {<= "0.3.1"}
             "matita" {<= "0.99.5"}
             "lablgl" {<= "1.07"}
             "frama-clang" {= "0.0.14"}

But that’s weird because lablgl does nor use camlp5 anymore, IIUC.

3

A quick look seems to show that the commits allowing lablgl to build without camlp5 require setting the CAMLP4O variable to no, which is not done by default, so the camlp5 dependency was re-added to the lablgl opam package by repository maintainers.

4

I see, so maybe there would be a quick fix to make lablgl installable again on ocaml 5.3 ?

5

In case you see this, I am investigating. Will report back.

7

OK, I have investigated, and now know what the problem is, as well as how to fix it. Also, why there is no easy workaround except to apply the patch. So ….. here we go.

First, here’s the PR for lablgl: A fix to make the camlp5 build work. by chetmurthy · Pull Request #13 · garrigue/lablgl · GitHub

What was the problem

BTW, all of this is documented in CHANGES for the 8.03.00 release of Camlp5, which came out with OCaml 5.2.0 support. It was at that time that lablgl.1.07 stopped being supported (via a conflicts stanza in opam).

The problem is that OCaml 5.2.0 introduced raw identifiers, and this required changing Camlp5’s pretty-printers. Camlp5 has multiple syntaxes, and each syntax has different keywords. So when you emit in some syntax, you need to tell the printing apparatus the keywords; then if an identifier is a keyword, it is printed as a raw-identifier. Remember that Camlp5 can parse in one syntax, and pretty-print in another. So this situation can happen.

The solution was to add a module that contained the list of keywords for that syntax. So there are r_keywords.cmo and o_keywords.cmo. These need to be loaded before pr_r.cmo and pr_o.cmo respectively.

What is the fix (to lablgl)

Camlp5 has supported both using ocamlfind packages to load its preprocessors when compiling, AND using a small extension of ocamlfind called not-ocamlfind in order to do preprocessing only. So instead of writing something like

camlp5 pa_r.cmo .... pr_o.cmo

you can write

not-ocamlfind preprocess -syntax camlp5r -package ....,camlp5.pr_o

So making this change to lablgl fixes the problem.

NOTE: Notice that in that first camlp5 … invocation, depending on the version of camlp5, you might need to use pr_o.cmo or o_keywords.cmo pr_o.cmo. But with the second invocation, camlp5.pr_o always works, b/c the findlib package contains the required filenames.

Why this bug is somewhat pernicious and weird (and not obvious)

lablgl.1.07 has two files that need to be processed by camlp5: src/var2switch.ml4 and src/var2def.ml4. the postprocessed files are included in the package source, and the last-modified times are what you would expect so that Make will not try to recompile (.ml4 → .ml) (hence needing camlp5). And it works as expected, IF YOU RUN MAKE in the source-directory.

So why doesn’t it work when we do opam install ….? Well, after numerous runs, I conclude that the process of COPYING the source-tree into the opam-controlled build-directory does not preserve last-modified times (HAHAHA) so when you run make over in the build-directory, SOMETIMES the last-mod times cause Make to want to regenerate the .ml files from the .ml4 files, and BOOM you need camlp5 for that.

So: if you try to install with opam install, it might work, and it might not. All depends on the mod-time-stamps, it seems.

5 Likes
8

Thanks for your investigation!

I have put up a fork of lablgl stripped out of Togl and Glut, and it seems to install reliably for me

(and for the ocaml CI)

I didn’t anything for the timestamp issue, though, so maybe I was just lucky

9

I might be wrong, but I don’t expect new developments to take place on lablgl, so wouldn’t it be reasonable to simply remove ml4 files and get rid of ocamlp code altogether?

10

I certainly cannot disagree with you. I don’t know anything about lablgl, so I made the smallest change that would fix the problem.

11

A bit aside answer : you could move to opam - gles3

This is complete enough to do things and would need more backends (OSX, wayland, etc)

12

thanks the for hint but this does not really solve my issue since:

$ opam install gles3
The following actions will be performed:
...
  ↘ ocaml                   5.3.0 to 4.14.2     [required by gles3]
13

gles3 works on ocaml 5.3.0, try it from github. I probably have to do a pull request on the opam repository,

but it is easy to install the opam version.

By the way I have trouble getting a speeded using 5.3.0 domains for the examples/spheres (naive simulation of spheres with shadows).

14

thanks, I was able to install GitHub - craff/gles3: ocaml bindings for gles3 on linux, it works

but not on MacOS

15

If you have an X server under OS X with EGL (a rapid search is telling that might be difficult theses days), it should be possible.

But the best would be that someone develop a native port for OS X, which I can not do, having no such machine.

This means recoding the file ml_egl.c using native OS X C interface. Probably needs minor changes in the ML interface in particular to find a common view of the keyboard events in both cases. It also requires adapting the build process so that it works on both OSes.

This is probably not a huge work.

Note : I have managed to compile gles3 code to an android app …. So OS X and iOS would be nice.

Cheers,

Christophe

16

ok, so … maybe lablgl is too old and maybe it’s not worth spending effort to maintain it.

Nowadays the recommended openGL bindings seem to be tgls. However tgls does not expose legacy openGL (eg V2.x) with immediate mode (gl_begin/gl_end and so on), therefore it was not ok for my use case (which is to maintain oplot.)

So, well, I ended up writing a quick add-on to tgls for including the legacy API:

gl-legacy

It does not cover the full API, but it is enough for oplot ! In particular it has DisplayLists and the nice (imho) Feedback mode. It works for linux and macOS.

It can also be used alone (without tgls) but that’s probably quite limited.

2 Likes