On Windows, freshly built executables cannot be run

[whitequark]

... because they're named like foo.byte or bar.native.

They should be named foo.byte.exe or something.

[gasche]

I suppose (but I know little of the Windows ecosystem) that when running from a cygwin shell, .byte works fine, and that we only notice the problem now (people have used ocamlbuild on Windows for a while) because of attempts to run on bare-metal Windows ecosystem.

We could do as we do for -output-obj target, which is to have a target name that depends on the system. We have an Options.exe reference that can be added to the executable extensions. However, doing this change naively could mean that people for which ocamlbuild foo.byte worked before would suddenly have scripts breaking because only ocamlbuild foo.byte.exe is recognized on their system now. Or maybe this will never happen, because all people using ocamlbuild on Windows today use cygwin and those will magically have their Options.exe empty by default. Who knows? In any case, supporting both would be the safer solution, I think (this means duplicating some rules declarations, but so be it).

Other options would include keeping the target name foo.byte, but creating foo.byte.exe at copy time when creating a link to the target (built in the bild directory) in the project directory. I would guess that some users may already do that from their Makefile shell.

[bobot]

What if we juste add a .byte -> ,.byte.exe copy rule? The users of ocamuild must be aware of the differences since they must install the right one, so they can also ask ocambuild to build the right one.

[gasche]

Indeed, copy rules for executable extensions (also for .native) seem to be excellent ideas.

[dra27]

Can I cross-reference a quite long exchange on the original referencing issue about this (https://github.com/dbuenzli/topkg/issues/11) - the short summary is that I don't think anything should be changed (except fixing things related to the symlinks created to .byte and .native files not working properly on Windows - but as it happens, I'm already working on parts of that!).

[gasche]

I personally find @dra27 's proposal to just do nothing rather tempting, because it's the easiest solution by far. @whitequark, do you strongly feel that a solution such as @bobot's copy rules is required?

[whitequark]

@gasche I still haven't got around to replicating @dra27's findings a fresh setup. Anyway, the criterion I am going to use is that a freshly compiled file outside the _build directory must be runnable by a user as-is; I have already described why. If it's runnable because it's an .exe, that solves everything. If it's runnable because the installer sets up some registry hack, this is sub-par, because with literally every other toolchain (that generates files which doesn't require a crapload of DLLs to run) you can copy the executable on another computer and run it there.

[dra27]

I can see a case (though I still find it unnecessary) as a halfway house for the symlink (or copy) of the build artefact having .exe added - but not the actual artefact inside _build/ itself. As I say, .byte and .native are definitively runnable from command prompt (cmd, not just Cygwin) - but it may be masked by a different bug where ocamlbuild is creating symlinks which cmd cannot read. I also find your requirement of being outside the _build directory too broad. There are three locations to consider:

1. the _build directory (used by ocamlbuild, artefacts picked up by opam, oasis, etc.)
2. the project source directory (used by developers) - runnable from the command line certainly desirable; graphical shell not so much
3. the project's binary installation directory (used by end-users) - and I certainly agree that anything being installed there should have .exe but I also find it inconceivable that you'd package something for end-users containing .byte.exe or .native.exe so there will be renaming already by whatever build system you use to install or create binary packages

My concern with copying the rules is the unnecessary (and likely mistakes) it adds, say, to opam packaging, if the artefact being picked up from _build/ for installation may or may not have a .exe extension depending on whether the author of the build system chose to invoke ocamlbuild that way or not for Windows. It just seems more potential trouble/regressions for not enough gains amongst a community that for perfectly good reasons aren't familiar with Windows...

[whitequark]

@dra27 I agree about 3), and 1) probably doesn't matter. And the outcome of skipping fixes like this is keeping the community not familiar with Windows by placing ridiculous artificial barriers for any newcomers on Windows because you are too change-averse to add two fucking copy_rules.

[hcarty]

For (2), runnable from the graphical shell seems very desirable. I wouldn't want to have to install an in-development GUI application just to know if it will run properly from a graphical shell due to environmental or other issues.

[hhugo]

(except fixing things related to the symlinks created to .byte and .native files not working properly on Windows - but as it happens, I'm already working on parts of that!).

x-ref https://github.com/ocaml/ocaml/pull/462