Installation error on Windows, possibly due to missing .exe extension

[maroneze]

On a freshly-installed Windows 11, I installed opam using the instructions here, that is:

winget install Git.Git OCaml.opam
(& opam env --switch=default) -split '\\r?\\n' | ForEach-Object { Invoke-Expression $_ }

This resulted in having opam 2.5.0 and OCaml 5.4.1.

I then installed frama-c (opam install frama-c; I had to manually install alt-ergo 2.6.2 first, to avoid an issue with the installation of alt-ergo-free), cloned this repository and did opam pin add ..

I then tried creating an archive for frama-c, but got:

PS C:\Users\andr> opam-oui frama-c

<><> Initialising opam ><><><><><><><><><><><><><><><><><><><><><><><><><><>  🐫
Package frama-c.32.0 found with binaries:
  - frama-c-config
  - frama-c-ptests
  - frama-c-script
  - frama-c-test.sh
  - frama-c-wtests
  - frama-c
  - ivette

<><> Creating installation bundle <><><><><><><><><><><><><><><><><><><><><>  🐫
Fatal error:
OpamSystem.File_not_found("C:\\Users\\andr\\AppData\\Local\\opam\\default\\bin\\frama-c-config.exe")
PS C:\Users\andr> C:\\Users\\andr\\AppData\\Local\\opam\\default\\bin\\frama-c-config.exe
C:\\Users\\andr\\AppData\\Local\\opam\\default\\bin\\frama-c-config.exe : Le terme «C:\\Users\\andr\\AppData\\Local\\opam\\default\\bin\\frama-c-config.exe» n'est pas reconnu comme nom
d'applet de commande, fonction, fichier de script ou programme exécutable. Vérifiez l'orthographe du nom, ou si un chemin d'accès existe, vérifiez que le chemin d'accès est correct et
réessayez.
Au caractère Ligne:1 : 1
+ C:\\Users\\andr\\AppData\\Local\\opam\\default\\bin\\frama-c-config.e ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\\Users\\andr...ma-c-config.exe:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Indeed, ls C:\\Users\\andr\\AppData\\Local\\opam\\default\\bin shows, among others:

-a----         2/20/2026  12:01 PM            592 frama-c-config
-a----         2/20/2026  12:01 PM        6185206 frama-c-ptests.exe
-a----         2/20/2026  12:01 PM           9276 frama-c-script
-a----         2/20/2026  12:01 PM          17203 frama-c-test.sh
-a----         2/20/2026  12:01 PM        5759047 frama-c-wtests.exe
-a----         2/20/2026  12:01 PM       34266963 frama-c.exe

So frama-c-config and frama-c-script (which are in fact shell scripts) exist, but frama-c-config.exe does not exist.

In this case, I guess the scripts could just be skipped, even if ideally we'd like to be able to run them. I don't know if there's a way to "wrap" them inside a call to Cygwin, but in any case, I believe that skipping such files might be useful, and possibly adding a "Limitations" (or similar) section to the README, stating that "on Windows, binaries which are shell scripts are not installed", or something similar.

If it's an issue with my installation, please tell me, I can try to recompile or reinstall some things and try again.

[NathanReb]

CC @ddeclerck I remember seeing some logic around missing .exe extensions in the windows backend, does that ring a bell?

Would it make sense to install them as is even if only to simplify the life of oui users and letting them share a config between windows and other systems, as we originally intended?

My impression is that we have some logic that looks up executables with an extra .exe extension on windows, we could probably have it instead only look it up if the name specified in exec_files can't be found, essentially allowing you to write:

  "exec_files": ["frama-c", "frama-c-config"],

creating an installer that would install both frama-c.exe and frama-c-config on Windows.

@maroneze I think it's worth mentioning that we don't really expect opam oui to work for frama-c, in particular, the binaries installed in your opam switch are not relocatable. I'd advise that you instead follow the workflow described here.

[ddeclerck]

I remember seeing some logic around missing .exe extensions in the windows backend, does that ring a bell?

Yes, this was tackled by PR #109, with the addition of a System.maybe_exe call that automatically adds a .exe extension when needed (and checking the file actually exists with that extension - otherwise it falls back to the name without extension).

The WiX backend code has been adjusted to use this call when executable files are references. But there might be places outside the WiX backend where this might be needed too. According to the output above, the code fails during the bundle preparation, before calling the backend.

The .json file used to produce the bundle could be useful.