-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a .mllib -> .cmxs rule #131
Comments
We should have a testcase to make sure that the ordering is as we expect. Armael, this should go in P.S.: Thanks a lot! |
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. |
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 |
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", []) ();; |
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 This suggests that it should be possible to simply change the relative priority of the two rules, to make sure that when a 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 |
Also: apologies, Armael, for not noticing the issue earlier :-) Right now I'm thinking of reverting the |
TBH I wonder who and what the use case would be for someone relying on the current behaviour. Also IIRC oasis does generate |
Yeah, maybe it is ok handle this as a low-key change -- just like we did so far. |
(I actually think it will rather fix the |
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. |
For the record: the legacy (0.9.3 and before) rule order hasn't been changed since Nicolas implemented |
I understand now why this order was initially chosen (sorry for using this issue as a talking pillow, but it's helpful): if you put the I am tempted to just drop the While we are at it, it would be nice if the change also fixed bug #77 -- I'll have to test against their repro case. (Edit: no, #77 is the stuff of nightmares, it is not directly related and looks super-hard to fix.) |
So the minimalistic route of #135 did not go as well as planned: this immediately broke the build of some packages so the release was reverted from OPAM -- see ocaml/opam-repository#8155. I think that we need to go back to the drawing board on this I would like to make another release with the safe stuff in any case, hopefully in the next few days. |
So just to trim this down a bit, with a pin on 0e247d4 the
|
So
If I go back to ocamlbuild 0.9.3
So it seems that |
Thanks for the reports. This also looks fairly similar to the
|
Yes basically the |
Ah no I didn't realize that in tsdl it was building from the
|
(but I think for sure it gets that |
So passing
|
But we need to be careful here. Basically are |
So a P.S.: I have to work on something else that is also urgent, so I may not be as reactive as you yourself proved to be -- thanks again. |
(Assuming that there is no direct way to get the preserve-linker-arguments behavior from the compiler,) One thing we could do is call |
Just to make sure I understand. In the
|
In fact it seems to me that we could eschew 2. and rely on the dynlinkable stubs that are to be installed in |
Also rather than
|
Instead of
All the -lXX from the .cmxa are passed to the linker, which will usually decide to link the stubs statically and the rest dynamically. We use a variant of this in our jenga rules as we handle the linking of stubs by hand. |
BTW, relying on the dynlinkable stubs in stublibs would be a bit tedious as you would need to properly setup |
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
The text was updated successfully, but these errors were encountered: