Avoid running bytecode files during the ocamlbuild build process
This change doesn't do much, this isn't exactly a speedup nor should it change something functionally, but i found it weird that the ocamlbuild build process was running bytecode programs while i was debugging an issue on Windows that a Discord user got stuck by:
#=== ERROR while compiling ocamlbuild.0.16.1 ==================================#
# context 2.4.1 | win32/x86_64 | ocaml.5.3.0 | https://opam.ocaml.org#a8ca1f2ed32a2e0c0ef612751a5c8138ba63053e
# path ~\AppData\Local\opam\default\.opam-switch\build\ocamlbuild.0.16.1
# command ~\AppData\Local\opam\.cygwin\root\bin\make.exe check-if-preinstalled all opam-install
# exit-code 2
# env-file ~\AppData\Local\opam\log\ocamlbuild-36448-e77703.env
# output-file ~\AppData\Local\opam\log\ocamlbuild-36448-e77703.out
### output ###
# [...]
# mv tmp-nat/ocamlbuild_pack.o src/ocamlbuild_pack.o
# ocamlopt.opt -w @14@29 -w +L -w +R -w +Z -I src -I plugin-lib -I bin -I +unix -safe-string -bin-annot -strict-sequence -c plugin-lib/ocamlbuild_plugin.ml
# ocamlopt.opt -w @14@29 -w +L -w +R -w +Z -I src -I plugin-lib -I bin -I +unix -safe-string -bin-annot -strict-sequence -c plugin-lib/ocamlbuild_unix_plugin.ml
# ocamlopt.opt -w @14@29 -w +L -w +R -w +Z -I src -I plugin-lib -I bin -I +unix -safe-string -bin-annot -strict-sequence -c bin/ocamlbuild.ml
# ocamlopt.opt -I +unix -I src -o ocamlbuild.native -I +unix unix.cmxa src/ocamlbuild_pack.cmx plugin-lib/ocamlbuild_plugin.cmx plugin-lib/ocamlbuild_unix_plugin.cmx bin/ocamlbuild.cmx
# ocamlopt.opt -a -o plugin-lib/ocamlbuildlib.cmxa src/ocamlbuild_pack.cmx plugin-lib/ocamlbuild_plugin.cmx plugin-lib/ocamlbuild_unix_plugin.cmx
# ocamlc.opt -I +unix unix.cma src/ocamlbuild_pack.cmo -I src man/options_man.ml -o man/options_man.byte
# ./man/options_man.byte > man/ocamlbuild.options.1
# Fatal error: cannot load shared library dllunixbyt
# Reason: A dynamic link library (DLL) initialization routine failed.
#
# make: *** [Makefile:201: man/ocamlbuild.options.1] Error 127
I believe this PR should fix this particular problem, although i suspect it might fail later in another package. I'm not exactly sure what the reason behind this failure is, but if someone has an idea…
No strong opinion here. The resulting build is slightly more complex and I'm not sure there are clear benefits, but if you feel that this is better I'm happy to trust you and go for it.
My guess would be that the user you are working with is hitting a Windows-specific issues related to dynamic linking of OCaml libraries -- ocamlbuild may be the first package to do this that they are trying to build. This may be due to a flexdll-level issue, or maybe just that the specific Windows configuration that they are using does not support dynamic linking? (I would expect that most Windows setups do support this.) See https://github.com/ocaml/ocaml/issues/13704 for a similar report (not related to ocamlbuild, possibly more to an environment-setup issue).
If the user problem is really that dynamic linking does not work (or maybe just dynamic linking of bytecode libraries, no native libraries), I don't think that the change you propose will solve their problem. For example, they would probably get the same issue when they try to use the toplevel seriously -- which is more common these days than ocamlbuild.