Skip to content

Better isolation of .cm* files and support of private modules #427

@ghost

Description

Currently we always wait for all the rules of a directory to be loaded before executing any rule from this directory. Technically, we could start executing rules that don't depend on globs from this directory before all the rules are known. That might be useful when we add support for dynamic rules for instance. Indeed, it seems quite natural to write something like this for instance:

(executable ((name foo) (module (foo))))

(rule (with-stdout-to jbuild.inc (run ./foo.exe)))

(include jbuild.inc)

There is however one issue with such approach: because the compiler uses include directories, the compilation of any .ml/.mli file implicitly depend on *.cmi. In fact, there is already an issue currently when there are several independent libraries in the same directories, since they can see each others modules. Though, the problem gets worse if we start building before we have loaded all the rules: because we can only delete stale artefacts when all the rules are known, we might end up leaving stale .cmi files and the compiler could end up reading them.

Solution

The idea is to put the .cm* files in sub-directories. For instance we could put the .cm* files for a library foo in a sub-directory .foo.objs. All the rules for this sub-directory would always be all generated at once, so we wouldn't have the issue describe before.

Private modules

This should provide a simpler way to support private modules: the .cm* files for private modules of libraries could be stored in .foo.objs/private. This way we could easily control who can see them by passing or not the relevant -I .../private option.

Work

There should be only three things to change:

  1. the path to the various .cm* files
  2. the include paths passed to the various tools
  3. merlin files

We could proceed as follow:

  • change the functions Module.cm*_file to take an obj_dir argument rather than a dir one, as well as various functions in gen_rules.ml returning other OCaml object files
  • define obj_dir in library_rules and executables_rules appropriately and fold these values everywhere needed
  • adapt Lib.include_flags, Lib.link_flags, ...
  • adapt merlin.ml

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions