Expected Behavior
When a module is autogenerated as exposing all modules as library, it should be possible to access all submodules without issues.
An example of this is opam-monorepo which declares Duniverse_lib, but doesn't have a duniverse_lib.ml, so dune generates one which contains references to all modules in the library. This works fine until dune-lang 3.5, but past that the auto-generated duniverse_lib.ml is marked as deprecated, thus leading to build failures if deprecation warnings are configured to be errors.
Actual Behavior
Since #6126 in dune-lang 3.5+ modules that are not meant to be accessed are marked as deprecated. This is nice, but unfortunately it also affects packages which don't have a main entry-point module, thus any access to the library causes deprecation warnings.
Reproduction
Specifications
- Version of
dune (output of dune --version): 3.6, anything that supports dune-lang 3.5+
- Version of
ocaml (output of ocamlc --version) 4.14
- Operating system (distribution and version): Fedora Linux
Expected Behavior
When a module is autogenerated as exposing all modules as library, it should be possible to access all submodules without issues.
An example of this is opam-monorepo which declares
Duniverse_lib, but doesn't have aduniverse_lib.ml, so dune generates one which contains references to all modules in the library. This works fine until dune-lang 3.5, but past that the auto-generatedduniverse_lib.mlis marked as deprecated, thus leading to build failures if deprecation warnings are configured to be errors.Actual Behavior
Since #6126 in dune-lang 3.5+ modules that are not meant to be accessed are marked as deprecated. This is nice, but unfortunately it also affects packages which don't have a main entry-point module, thus any access to the library causes deprecation warnings.
Reproduction
Specifications
dune(output ofdune --version): 3.6, anything that supports dune-lang 3.5+ocaml(output ofocamlc --version) 4.14