I’d like to announce the first version of raylib-ocaml, a binding to the awesome raylib game development library. The release can be found on opam as “raylib”.
The bindings are nearly complete, as far as functions and types go, but only a subset was tested so far. I will work on bringing more of the numerous examples of the C version to OCaml in the future.
Currently, raylib-ocaml only works on Linux, but I plan to support Windows (and possibly other targets) in the future.
Feel free to give it a spin and please report any issues you run into.
make PLATFORM=PLATFORM_DESKTOP GRAPHICS=GRAPHICS_API_OPENGL_21 -B
make PLATFORM=PLATFORM_DESKTOP GRAPHICS=GRAPHICS_API_OPENGL_21 -B RAYLIB_LIBTYPE=SHARED
Then the pure C examples provided with raylib do work as expected.
How to compile the ocaml bindings to use this make option?
Does the ocaml binding include the underlying C lib? Is it allowed in opam?
The ocaml library does indeed include the C library. I thought it would be more convenient to compile it at build time than requiring the user to (globally) install the C lib themselves. I don’t know whether this is allowed or not in opam. If it’s not, I will change it.
Compiling the C lib automatically of course leads to problems like yours, where the compile options you need don’t match with the ones I chose. As an alternative, dune could look for a globally installed version and only compile the C lib if it cannot find one. This would solve your problem, I think.
Is there a way to specify options through opam (and dune subsequently)? Such that a user could install raylib, but with backend gl2.1 instead of gl3.3 for example?
@fccm If you pass (at build time) the GRAPHICS option through an environment variable, it should be picked up by the Makefile. On my PC, I could create a opengl 2.1 executable by setting it export GRAPHICS=GRAPHICS_API_OPENGL_21:
But when I tryed to install it with opam install --working-dir . I get the following error:
$ opam install --working-dir .
[...]
# File "src/c/dune", line 9, characters 16-48:
# 9 | (include_dirs %{project_root}/src/c/vendor/src))
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# Error: Include directory "vendor/src" does not exist.
I have another question about this build, if I compile a mini-game with this binding using gl2.1 and upload it on itch.io, will it work for people using a more recent computer with gl3.3?
(with my sdl2 binding it seems that my binary executables work on other computers, for both linux and windows, I built on Windows 7 and it still works on Windows 10 targets. And seems like the linux build also works for other people using linux too)
Good to know!
The error comes from the fact that the raylib source code is a submodule of the bindings repo, and git doesn’t clone these automatically, if you don’t tell to explicitly with --recursive. If you initialize the submodules with git submodule update --init --recursive your code should work. I will put up a notice into the README about this.
Generally, an opengl 3+ driver should be able to work with gl2.1, so yes, this will work.
The raylib C library is linked statically, so the executables only link against some common Linux libs (X, pthread, m), which are available on nearly every distro. As long as you build on a distro, which sticks to the usual directory layout (ie not NixOS), the build should be portable.
The same goes for windows, where only some windows libs are linked.
Yes, it is. Since version 0.2 it works with the mingw64 variant of the compiler.
Unfortunately, ctypes does not support the msvc switches, so no luck there.
When I last used it on windows, installing worked flawlessly from opam.
Oh sorry for my concise question. What I wanted to know is if I can use it to build windows, Linux and MacOS binaries. I’m interested on raygui so I can build quick tools for my family and coworkers on a cross-platform fashion but using a nice language that doesn’t bloat their computers.
That is very cool, thabks dot the links.
I took a look at the repository and I saw it uses a build matrix for cross compile, but there are no releases available.
How does he handle the cross compilation then?
I do use github actions for cross compilation, but don’t upload every build as a new release on github.
Instead I use an upload-artifact action to save the build artifacts instead of discarding them. They show up in the actions tab next to each run, see Build in release mode and strip · tjammer/tacs@662e2a2 · GitHub
The action can be found here
I guess one could also automatically create a github release on each new tag or so but I haven’t looked into that.
As for the raygui bindings: They work in principle, as demonstrated by the example. But the usability is sub-optimal compared to something like dear imgui. The reason for that is that raygui makes the user handle all the widget state, which makes the API more verbose than necessary. Hopefully one day we can have dear imgui bindings.
Thanks for your detailed answer. I just assumed that the artifacts action was uploading it as part of a release, but your need to create a release before I guess. There are plenty of actions for automatically bump version tags and create releases, but I don’t know which to recommend.
About the raygui library, how different is that from, let’s say, manage the state on the browser for example? Will it be possible to implement some kind of Elm like flow or it is much more than that?
Imgui looks impressive, indeed, but I don’t know how well can it be translated to a functional way of working like the one OCaml has.
