opam install ocamlmod fails on Cygwin32

[lcdunstan]

I felt like giving OCaml and OPAM on Windows a try and had a lot of issues, but the latest one looks like a portability problem in OPAM. The error is:

#=== ERROR while installing ocamlmod.0.0.7 ====================================#
# opam-version 1.2.2 (391297300524717e1475deaea37bca287c7f5e36)
# os           cygwin
# command      install -m 0755 /home/luked/.opam/system/build/ocamlmod.0.0.7/_build/src/ocamlmod.byte /home/luked/.opam/system/bin/ocamlmod
# path         /home/luked/.opam/system/build/ocamlmod.0.0.7
# exit-code    1
# env-file     /home/luked/.opam/log/log-1180-c61e7b.env
# stdout-file  /home/luked/.opam/log/log-1180-c61e7b.out
# stderr-file  /home/luked/.opam/log/log-1180-c61e7b.err
### stderr ###
# install: cannot create regular file ‘/home/luked/.opam/system/bin/ocamlmod’: File exists

The problem is that "ocaml setup.ml -install" correctly copies ocamlmod.byte to ~/.opam/system/bin/ocamlmod.exe, but the install command above specifies the destination without the ".exe" extension, and Cygwin's "install" doesn't permit such ambiguity. The contents of "ocamlmod.install" are:

bin: ["_build/src/ocamlmod.byte" {"ocamlmod"}]

Purely as a test I tried changing this (which seems to be impossible using pinning alone?) to bin: ["_build/src/ocamlmod.byte" {"ocamlmod.exe"} and this fixes the problem, but obviously is only appropriate on Windows, so do you agree that OPAM should append ".exe" automatically somehow? I also tried bin: ["_build/src/ocamlmod.byte"] and it results in installation of the file using both names ("ocamlmod.exe", "ocamlmod.byte").

Alternatively, is there some clean way to fix this in the opam file for ocamlmod?

P.S. I did notice the existence of #246

[lcdunstan]

I looked at a few other packages that do install successfully, e.g.:

• cppo works because the (non-OASIS) build creates cppo.exe, and I believe "install" works OK if both the source and destination paths omit the ".exe".
• ocamlify does use OASIS but for some reason the executable "ocamlify.byte" is copied to "ocamlify" (with no filename extension) after building, so it doesn't need to be renamed during installation. Surprisingly Cygwin allows running executables without the ".exe" extension, unlike native Windows.

[AltGr]

Unless we ask for all packages to dynamically generate their .install file with the proper extensions, it sounds like it could be a suitable workaround to add .exe, if absent, to the destination of files in the bin: section when running on cygwin or windows ; not fond of such hacks, but cygwin is already full of them...

Not sure if it's worth the trouble as .install will hit more issues with other extensions as well ; putting a layer of magic on top of cygwin's install command layer of magic doesn't sound like a nice fix. I'm open to ideas!

[dbuenzli]

not fond of such hacks,

I would also be rather against this. .install files are straightforward to interpret the way they exist now, let's not try to put magic at every layer of the system. Build systems should be fixed.

[lcdunstan]

Fair enough. What are you proposing as an alternative? Some random thoughts:

• When a package is authored by one person but packaged by someone else (e.g. ocamlmod) it seems unreasonable to change the original build system, so there could be some "less magic" functionality added to OPAM, e.g. an optional separate .install file just for Windows, or new optional notation inside .install, or something.
• Ask the author of OASIS to add the .exe extension automatically on Windows, which would presumably help a significant percentage of packages (but I am only guessing). This relies on Cygwin magic in install to avoid changes to .install files.
• For packages that are maintained by the author of the code we could submit bug reports for every applicable package to ensure that they generate executable files with a .exe filename extension, particularly for those that don't use OASIS.
• Modifying Cygwin itself is unlikely to be feasible.
• Create a replacement for Cygwin's install that includes different magic (not very cool).
• Suggestions?

[dbuenzli]

Le vendredi, 17 juillet 2015 à 10:08, Luke Dunstan a écrit :

Fair enough. What are you proposing as an alternative? Some random thoughts:
When a package is authored by one person but packaged by someone else (e.g. ocamlmod) it seems unreasonable to change the original build system,

Why not ? Patch (all the needed functionality is already in opam, see patches: field) and report upstream.

Ask the author of OASIS to add the .exe extension automatically on Windows, which would presumably help a significant percentage of packages (but I am only guessing).

If oasis generates broken windows installs this should certainly be reported there. But rereading your initial issue it seems to me that it's the package description itself that is broken. It should not have a .install file since oasis is in charge of (correctly it seems) installing it.

Best,

Daniel

[lcdunstan]

OK, thanks. I did wonder about whether there was a good reason for .install to overlap with what OASIS is doing.

[Chris00]

@Infidel I updated ocamlmod with a new stratedy (not yet perfect IMHO). May you confirm it fixes the reported bug?

BTW, it would be nice to have a test script for Appveyor. Would you have some code ready?

[lcdunstan]

Works for my test. Appveyor in progress https://ci.appveyor.com/project/infidel/ocamlmod-appveyor (it's just the opam appveyor.yml plus a few steps)