Re: [Caml-list] ocamldep, transitive dependencies, build systems, flambda

[Gabriel Scherer <gabriel.scherer@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]

I think that the question was more about how owner of large codebases
approach the problem in practice today, but in terms of "what do people
think about this" I would still stand by my comment on the mantis issue:

ocamldep is an heuristic tool based on some assumptions about how OCaml
> users typically organize their development. I'm not sure it is reasonable
> to try to evolve it into an omniscient tool capable of dealing with your
> sophisticated file manipulations. That's what "by hand" compilation scripts
> (or special-case tools designed hand-in-hand with your quite specific build
> system) are for: absolute flexibility.
>
> I'm not convinced in particular that doing deep modification to the
> semantics of .cmi files and/or the compilation process to work around
> limitations of ocamldep is such a good idea.
>
> I would rather welcome richer ways to inform the compiler of the mapping
> from Ocaml world compilation unit names to filesystem object files than the
> current rules allow; and/or potentially a type-checker design facilitating
> discovery of dependencies and interaction with library providers and build
> systems (implement what currently is ocamldep as a layer between parsing
> and type-checking, that resolves such mapping, is able to access existing
> .cmi files for semantically accurate naming information, and to make
> asynchronous queries to a build system for the missing .cmi).


That said, I also know that Alain has explored these options (eg.
intercepting calls to other files in the compiler) further than many of
thus, so he probably has good reasons for sticking to a practical
compromise.

On Tue, Jul 5, 2016 at 9:06 AM, Hongbo Zhang (BLOOMBERG/ 731 LEX) <
hzhang295@bloomberg.net> wrote:

> Hi Alain,
> I found the same problem when we did aggressive cross-module inlining in
> bucklescript. It makes it too hard to build a correct build system, so
> currently the inlining will stop at B, it will not propagate to C, what do
> other people think about this?
>
> From: alain.frisch@lexifi.com At: 07/04/16 12:49:32
> To: caml-list@inria.fr
> Subject: Re:[Caml-list] ocamldep, transitive dependencies, build systems,
> flambda
>
>
>
> Moreover, flambda makes the problem actually quite a bit worse. Indeed,
> B.cmx can now contain symbolic references to A.cmx, and when compiling
> C.cmx, the compiler will complain that it cannot find A.cmx (typically
> when a function in B is inlined in C and calls a function in A). This
> is warning 58. Simply disabling the warning does not work, since an old
> version of A.cmx could remain in lib1/pub, leading to mismatched
> implementation digests and to unreliable parallel build.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 3581 bytes --]