compilation order of packed files

[agarwal]

Say B depends on A, and you want to pack these into a module Mypack. Then, the following commands are what you must enter:

$ ocamlopt -c -for-pack Mypack -o a.cmx a.ml
$ ocamlopt -c -for-pack Mypack -o b.cmx b.ml
$ ocamlopt -pack -o mypack.cmx a.cmx b.cmx

The cmx files must be listed in dependency order in the last command, when the pack is constructed. In addition, one must not swap the first two commands. It matters. Else, the third command gives an error like:

Error: File b.cmx was compiled without access to the .cmx file
       for module A, which was produced by `ocamlopt -for-pack'.
       Please recompile b.cmx with the correct `-I' option
       so that a.cmx is found.

I don't immediately see how to solve this. In 1c130f152dc05d72586fcb089cdacc7fd4c8a0b7, I introduced a fix by sorting the deps of the rule that creates a pack. However, this is fragile for a couple of reasons:

• Ocamlbuild appears to respect this order, but I don't think there is any guarantee that deps will be compiled in the order they are listed.
• The reason I was doing the sort within the action, as opposed to prior to the rule declaration, is to handle dynamically generated ml files. Now, some of the ml files may not even exist when ocamldep is being called, so their content can't be accounted for.

Reminder:

• [x] Need to at least make sure the deps is complete. Since ocamldep silently ignores ml files that don't exist, we could be truncating the true list of deps. Fixed in 757978ff1ccb71eacdd3b589bcebf0d88cfebc5d.

[agarwal]

6b8d6122ee75f9ce29ac23d3ae53d0d6e7da9c89 improves the situation. I tested on several projects, and this seems to work but there's still one issue:

The cmo files seem to get built in the order they are listed (which we sorted by calling ocamldep), but the semantics of this list doesn't impose such an order. In fact, it is the opposite. The items of this list are allowed to get built in parallel, and so now we're relying on the fact that we don't set ocamlbuild's -j option.

[agarwal]

Commit 064d8e08e3e8c379936fbdfdc4ba9f07fa2d59b5 possibly resolves this issue, at least in terms of correctness. However, the solution is not efficient. As the commit message says, I've now prohibited parallel builds for all cmo/cmx files in a project. For most projects this will constitute the majority of the overall build, so this is pretty bad.