[new release] raylib, raygui and raylib-callbacks (1.6.0)

[tjammer]

CHANGES:

• Expose name field of ModelAnimation.t (thanks @thethrung)
• Add new raylib-callbacks package to expose raylib callback APIs. It brings a new dependency (ctype-foreign), hence the new package
• Temporarily fix raylib FLAC bug (thanks @rossberg)

[tjammer]

Does anyone understand what went wrong on the cygwin build?
The msys2 build was failing in the last version already (and we decided to not bother at the moment)

[rossberg]

When I tried this locally before, I had to manually install a libffi package for Cygwin. Not sure why, I would think that ctypes-foreign includes it as a dependency. Unfortunately, the CI log cuts the relevant lines, so this may or may not be the reason.

[jmid]

Does anyone understand what went wrong on the cygwin build?

Looking at the CI logs:

  <><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
  -> retrieved ctypes-foreign.0.24.0  (cached)
  -> retrieved mingw-w64-shims.0.2.0  (cached)
  -> removed   mingw-w64-shims.0.2.0
  -> installed conf-pkg-config.4
  -> retrieved raylib-callbacks.1.6.0  (cached)
  -> installed conf-mingw-w64-libffi-x86_64.1
  -> installed conf-libffi.2.0.0
  -> installed mingw-w64-shims.0.2.0
  -> installed ctypes-foreign.0.24.0
  [ERROR] The compilation of raylib-callbacks.1.6.0 failed at "dune build -p raylib-callbacks -j 3 @install".
  
  #=== ERROR while compiling raylib-callbacks.1.6.0 =============================#
  # context     2.5.0 | win32/x86_64 | ocaml.5.4.0 | file://D:/a/opam-repository/opam-repository
  # path        D:\opamroot\default\.opam-switch\build\raylib-callbacks.1.6.0
  # command     D:\opamroot\default\bin\dune.exe build -p raylib-callbacks -j 3 @install
  # exit-code   1
  # env-file    D:\opamroot\log\raylib-callbacks-5416-32703f.env
  # output-file D:\opamroot\log\raylib-callbacks-5416-32703f.out
  ### output ###
  # [...]
  # -> required by
  #    _build/install/default/lib/stublibs/dllraylib_callbacks_c_stubs.dll
  # -> required by _build/default/raylib-callbacks.install
  # -> required by alias install
  # (cd _build/default/src/c/raylib_callbacks && .\raylib__function_gen__Functions__Functions.exe ml raylib_stubs) > _build/default/src/c/raylib_callbacks/raylib__c_generated_functions__Functions__Functions.ml
  # Command exited with code 0xc0000135.
  # -> required by
  #    _build/default/src/c/raylib_callbacks/raylib__c_generated_functions__Functions__Functions.ml
  # -> required by
  #    _build/install/default/lib/raylib-callbacks/__private__/raylib_callbacks_c/raylib__c_generated_functions__Functions__Functions.ml
  # -> required by _build/default/raylib-callbacks.install
  # -> required by alias install

the successful install of conf-mingw-w64-libffi-x86_64.1 and conf-libffi.2.0.0 indicate that the problem is elsewhere.

Command exited with code 0xc0000135 which I (as a Windows illiterate) had to look up
https://stackoverflow.com/questions/11432940/what-does-error-code-0xc0000135-or-1073741515-exit-code-mean-when-starting-a
indicate that a relevant dll (perhaps dllraylib_callbacks_c_stubs.dll?) is not being found. 🤔

[rossberg]

Code 0xc0000135 is exactly what I got locally before installing libffi manually, after that it worked. I have no theory as for why, maybe it is a different libffi package that's required? I installed all of libffi6, libffi8, mingw64-i686-libffi and mingw64-x86_64-libffi just to be sure.

[jmid]

To help understand what's going wrong you can

• rerun the GH action with debug logging https://github.blog/changelog/2022-05-24-github-actions-re-run-jobs-with-debug-logging/
• another option is to add a flags: verbose field to the package as suggested in the wiki https://github.com/ocaml/opam-repository/wiki/How-to-deal-with-CI#annex
• a third option is add a verbose flag -v to the relevant line of the Windows workflow
  

  opam-repository/.github/workflows/windows.yml

  Line 116 in 2fd4164

  opam install --color=always --confirm-level=unsafe-yes "$pkg"

[mseri]

I am re-running with debug logging, but I am not expecting it will help. Unfortunately I don't have (machines or any recent experience with) windows

[rossberg]

So, I have a dumb question here: given that libffi versions like -6 and -8 are not fully ABI-compatible, where does the Opam package actually specify which version to depend upon? In the package description it doesn't seem to say anything specific, for no OS.

And on the flip side, how does ctypes-foreign know which ABI to target?

In my experiments with Raylib, it seemed to be looking for libffi-6.dll on Cygwin, but I'm not sure I understand where that decision is coming from.

[tjammer]

Thanks for digging a bit deeper on this. I don't have a windows machine (nor access to one atm) so I can only guess.
The opam package you linked splits into conf-mingw-w64-libffi-x86_64 and conf-mingw-w64-libffi-i686, and in our case conf-mingw-w64-libffi-x86_64 is taken. This then installs mingw64-x86_64-libffi which seem to contain libffi-6.dll (cygwin package description). The i686 one also points to libffi-6 so I don't see a path which would give us libffi8.

@rossberg Could you check which install of (libffi6, libffi8, mingw64-i686-libffi and mingw64-x86_64-libffi) makes the package work?