Turn off shimmed META files for OCaml 5.0+#5916
Conversation
nojb
left a comment
There was a problem hiding this comment.
LGTM; I'm only wondering about the fact that the stdlib directory takes precedence over the ocamlfind/opam load path. I understand this preserves the existing behaviour, but is it the "best" order? Or perhaps we don't care?
My rationale (having initially done it the other way around) came from the I'm personally happy with either. |
Sounds like a reasonable argument, good enough for me! |
|
The upstream OCaml PR has been merged, so this is good to go. It would be nice to have a Dune release with this PR around OCaml 5.0.0~alpha1, since at the moment the |
|
Rebased and changes added |
|
@dra27 I made the mistake of using the Github UI to rebase this branch in order to merge it (it had become out of date with |
Signed-off-by: David Allsopp <david.allsopp@metastack.com>
|
No problem - it's passing this time! |
|
Merged, thanks! |
…ne-site, dune-rpc, dune-rpc-lwt, dune-private-libs, dune-glob, dune-configurator, dune-build-info, dune-action-plugin and chrome-trace (3.4.0) CHANGES: - Make `dune describe` correctly handle overlapping implementations for virtual libraries (ocaml/dune#5971, fixes ocaml/dune#5747, @esope) - Building the `@check` alias should make sure the libraries and executables don't have dependency cycles (ocaml/dune#5892, @rgrinberg) - [ctypes] Add support for the `errno` parameter using the `errno_policy` field in the ctypes settings. (ocaml/dune#5827, @droyo) - Fix `dune coq top` when it is invoked on files from a subdirectory of the directory containing the associated stanza (ocaml/dune#5784, fixes ocaml/dune#5552, @ejgallego, @rlepigre, @Alizter) - Fix hint when an invalid module name is found. (ocaml/dune#5922, fixes ocaml/dune#5273, @emillon) - The `(cat)` action now supports several files. (ocaml/dune#5928, fixes ocaml/dune#5795, @emillon) - Dune no longer uses shimmed `META` files for OCaml 5.x, solely using the ones installed by the compiler. (ocaml/dune#5916, @dra27) - Fix handling of the `(deps)` field in `(test)` stanzas when there is an `.expected` file. (ocaml/dune#5952, ocaml/dune#5951, fixes ocaml/dune#5950, @emillon) - Ignore insignificant filesystem events. This stops RPC in watch mode from flashing errors on insignificant file system events such as changes in the `.git/` directory. (ocaml/dune#5953, @rgrinberg) - Fix parsing more error messages emitted by the OCaml compiler. In particular, messages where the excerpt line number started with a blank character were skipped. (ocaml/dune#5981, @rgrinberg) - env stanza: warn if some rules are ignored because they appear after a wildcard rule. (ocaml/dune#5898, fixes ocaml/dune#5886, @emillon) - On Windows, XDG_CACHE_HOME is taken to be the `FOLDERID_InternetCache` if unset, and XDG_CONFIG_HOME and XDG_DATA_HOME are both taken to be `FOLDERID_LocalAppData` if unset. (ocaml/dune#5943, fixes ocaml/dune#5808, @nojb)
|
EDIT: ah, i should’ve read the description... nevermind ^^" |
|
@kit-ty-kate is there anything that needs to be fixed? |
|
No, sorry i should’ve read the discussion before commenting. I think removing |
This is the case since ocaml#5916 (3.4.0). Signed-off-by: Etienne Millon <me@emillon.org>
This is the case since #5916 (3.4.0). Signed-off-by: Etienne Millon <me@emillon.org>
This is an update of #5824, compatible with the latest version pushed to ocaml/ocaml#11007. The current proposal is that from OCaml 5.0.0~alpha1, the compiler installs its own
METAfiles in directories under the Standard Library directory.The previous version was not able to guarantee the operation of Dune or opam's
ocaml-systembecause there wasn't a mechanism for reliably determining the location of the compiler'sMETAfiles. The latest revision proposes that the compiler'sMETAare therefore always installed in the same place, with Dune and ocamlfind using that fact to change their default search paths for packages accordingly.This PR, therefore:
METAfiles used for OCaml 4.x.default_ocamlpath(i.e. the compiler'sMETAfiles cannot be overridden by other findlib packages, as in Dune's behaviour for OCaml 4.x).There is one outstanding question, which is what to do about the
bytesshim package. OCaml is not proposing installing this package, partly because it doesn't reflect an actual library (thebytespackage expresses a property of thestdlibpackage) and also because it relates to back-porting, which is not something the compiler should directly be part of (i.e. the compiler proposes to own its packages, but thebytespackage has always been owned by findlib).There are several possible courses of action:
Meta.builtinscould continue to return a dummy abytespackage on 5.0bytescould be handled in a similar way tobigarray- so pruned at thelibrariesstanza for 5.xbase-bytesorocamlfindin order to pull in findlib's support for thebytespackageI'd personally advocate option 3, which is what the PR presently does, because, it's daft that
jbuildordunefiles have ever referred to thebyteslibrary. No version of jbuilder or Dune has ever targeted OCaml 4.01 or earlier, so addingbytesto alibrariesfield has always implied a no-op (unless I've missed something??). The fact it's always been a no-op makes option 2's proposal forbytesdifferent frombigarray. Dune is now correctly handling the ability to getBigarrayin a consistent way for OCaml 4.02-5.x, but the consistent way to getBytesfor OCaml 4.02-5.x is, um, not to do anything! It's a shame to do option 1 because it's yet another compatibility shim with no sunset.