Re: [Caml-list] Forcing OCamlbuild to compile a file before another

[Dario Teixeira <dario.teixeira@nleyten.com>]

Hi Gabriel,

> Currently there is nothing specific in ocamlbuild to support
> -no-alias-deps. What the open(Foo) flag does is to to pass the "-open
> Foo" option to ocamldep, which in turns merely adds Foo to the list of
> dependencies of the compiled module. My understand of the situation
> is that it guarantees that project using "-open ..." in their build
> system will build correctly with ocamlbuild, with two limitations:
> (1) if you use crazy recursive-but-not-really schemes, you'll get a
> circular dependencies error (2) if Foo is a list of aliases, it will
> act as a bottleneck in the dependency graph

I've opted to abandon "-open Foo" and now explicitly declare "open Foo" 
on the
source-code itself.  Besides avoiding issues with the build system, I 
think
the explicit approach will end up being clearer for someone reading the 
code
(less knowledge about the system outside the source code itself).


> Any good proposal to change the statu quo will of course be considered
> -- but I myself have little time to implement new OCamlbuild features 
> --
> and I will try to be as reactive on possible bugs (eg. #6755) as 
> possible,
> as the de-facto maintainer of ocamlbuild.

Yeap, I understand.  The good news is that it should be possible to use
module-aliases/no-aliases-deps/pseudo-circular-recursion within the 
current
OASIS+OCamlbuild framework with only minimal extra burden on the user,
and zero modifications to OASIS or OCamlbuild.

I had to bump my forehead against the wall a few times, but in the end 
I've
managed to get the full combination working on a toy example, and I'm 
confident
I can also get it to work on the much larger Lambdoc code base.  I'll 
keep
you posted...


> I am not sure what should be done about (1). The almost-recursive
> scheme was adopted by Jane Street for the extremely specific use-case
> of migrating an enormous code-base from -pack to -no-alias-deps, but
> I am not sure it is reasonable to expect it to work for other users
> (and I doubt it's wise to advertise it as such).

In my particular case, the impetus to abandon module packs stemmed not 
so
much from the fat-binaries and recompilation problems, but from issues 
with
the tooling (namely OCamldoc).  Either way, there are enough advantages 
to
module aliases and -no-alias-deps that I suspect more people will want 
to
use them, even if they are not widely advertised.


> In slightly more details: I think the idea of distributing a
> short-name-giving lambwiki.ml to your users is a good way to emulate
> -pack without the downsides of -pack, but that you could avoid using 
> the
> short names in the project itself (that is use Lambda_Parser explicitly
> rather than Parser). If you did this, the spurious cyclic dependencies
> disappaear, you can simply use ocamlbuild without any dependency hack,
> and your users see the short names.

Yeah, using long names internally and short names externally is my 
fallback
scenario.  However, the Lambdoc core modules are used so extensively 
from
within the library that it's worth spending some time trying to get 
short
names to work internally too.

Kind regards,
Dario Teixeira