Stdlib modules overlap

[art-w]

I have a funny situation when trying to use/integrate codept-lib: the library is not wrapped and some of its module names overlap with stdlib ones (e.g. Option or Unit, and I would prefer to write Codept_lib.Unit than fix the rest of my code to use Stdlib.Option). That's not a problem, I can wrap it on my end:

(library (name codept-lib_wrapped) (libraries codept-lib))

module Approx_parser = Approx_parser
module Ast_converter = Ast_converter
(* ... *)
module Unit = Unit
(* ... *)

Currently this is fine: dune always adds $(ocamlfind query codept-lib -i-format), for all dependencies listed in libraries, to compile every module. However, this is a wasteful default and one would hope to use Codept to be more precise about which libs are used by which modules! :)

And now we have an amusing issue: codept with -no-alias-deps correctly reports that my wrapper is just a bunch of aliases and can be compiled with no dependencies... which is true, but here without any -I the compiler will interpret module Unit = Unit as pointing to Stdlib.Unit! This leads to confusing error messages later ("type Codept_lib_wrapper.Unit.u does not exist"). I'm currently sidestepping the issue by compiling the wrapper with -nopervasives.

(I find it interesting that the compiler only cares to know that a unit.cmi exists (but it could be an empty file!), for it to take precedence over the pervasives. This only impacts module names provided by the stdlib: I suspect that I can compute the set of aliased module names from a codept signature and check for overlap with the stdlib to handle this edge-case :) )

[Octachron]

The worst offenders, Option and Unit, have been renamed to Ext_option and Comp_unit in the next version.