Add a .mllib -> .cmxs rule

[dbuenzli]

This rule should be put after the .mldylib -> .cmxs rule so that it doesn't override a possible (but unlikely) different explicit way of building the shared library for a library.

See also discussion there dbuenzli/uuseg#4

[gasche]

We should have a testcase to make sure that the ordering is as we expect. Armael, this should go in testsuite/internal.ml, to be run from testsuite/ as follows: OCAMLBUILD=$(pwd)/../ocamlbuild.byte ocaml internal.ml.

P.S.: Thanks a lot!

[gasche]

Closed by merging #132. Thanks @dbuenzli and @Armael

[gasche]

I'm suddenly confused: in 0.9.3 there was already a rule defined as follows

rule "ocaml: cmxa & a -> cmxs & so"
  ~prods:["%.cmxs"; x_dll]
  ~deps:["%.cmxa"; x_a]
  ~doc:"This rule allows to build a .cmxs from a .cmxa, to avoid having \
        to duplicate a .mllib file into a .mldylib."
  (Ocaml_compiler.native_shared_library_link ~tags:["linkall"] "%.cmxa" "%.cmxs");;

which is documented in the manual.

Why was a new rule necessary if this rule was present? Is there something that actually prevents it from working? Is there a conflict between this old rule and the new rule?

I am in the work of preparing a new release, and found out about this when giving finishing touches to the manual. I am considering reverting #132 from the release in order to give ourselves (that is, @Armael :-^ ) more time to think about this. Or it could still go in the release but be amended/removed if found redundant with the existing approach -- once this existing approach is fixed.

[Armael]

I don't have any particular opinion about whether the rule added in #132 is actually needed or not. I also discovered the existence of the cmxa -> cmxs rule while implementing it, but thought for some reason a mllib -> cmxs rule was also needed, because of this issue.

[gasche]

The following test case seems to work under 0.9.3:

let () = test "CmxsFromMllib"
  ~description:"Check that a .cmxs file can be built from a .mllib file"
  ~options:[`no_ocamlfind; `no_plugin]
  ~tree:[
    T.f "a.ml" ~content:"let a = 1\n";
    T.f "b.ml" ~content:"let b = true\n";
    T.f "foo.mllib" ~content:"A\nB\n";
  ]
  ~targets:("foo.cmxs", []) ();;

[gasche]

So it seems to me that what is happening is as follows: the "legacy" way to build a .cmxs file from a .mllib is registered with a weaker priority than the .cmx -> .cmxs rule (this is why the test above succeeeds in 0.9.3 while MllibOverridesCmx fails), so it only works when none of the included modules has the same name as the library that is being built.

This suggests that it should be possible to simply change the relative priority of the two rules, to make sure that when a .mllib and a .ml of the same name are present, the .mllib -> .cmxa -> .cmxs path has priority over the .ml -> .cmx -> .cmxs path.

However, this also highlights the fact that this change is in fact changing pre-existing behavior in ways that might in theory break things among our users. Indeed, someone might rely on the current ordering. I see why the new ordering is better, though: if both a .ml and a .mllib are present, getting the .cmx -> .cmxs semantics only require a one-line .mldylib file, while getting the .cmxa -> .cxms semantics requires a full copy of the .mllib file. It is better if the costly action is the default, so that users don't have to do it.

[gasche]

Also: apologies, Armael, for not noticing the issue earlier :-)

Right now I'm thinking of reverting the .mllib -> .cmxs rule, but keeping the various tests in place to have a clear picture of the next-release behavior. Before doing this, I would like to check that it is indeed possible to recover the current (master) behavior by changing the ordering of pre-existing rules. If that works, I'm not opposed to switching to the better (current master) semantics, and announcing the changes to users, but I would like to get a not-compatibility-breaking release out first -- would that mean that we will soon have to use 0.10?

[dbuenzli]

TBH I wonder who and what the use case would be for someone relying on the current behaviour. Also IIRC oasis does generate .mldylib files so while this would change the semantics it seems to be a low risk to me.

[gasche]

Yeah, maybe it is ok handle this as a low-key change -- just like we did so far.

[dbuenzli]

(I actually think it will rather fix the cmxs of packages rather than break them...)

[gasche]

I now think that I could investigate right now, try the reversed rule order, and if that works have the "simpler approach" (revert the new rule and change the order) in the release. I don't really want to play the revert+unrevert game if I can avoid it.