Bring back dune.1.0.0 compatibility#35
Conversation
|
The linker error is because of the new I think it should be consequence-free simply to rename |
dra27
left a comment
There was a problem hiding this comment.
Simplification possible to have sample-opam but use it by the current name internally.
6420248 to
a7e0415
Compare
|
Ah, I have just looked at this again in the context of #36 and also realise that this reverts a change in #31. In #23, I added This isn't strictly speaking "bringing back" Dune 1.0 compatibility, it's wallpapering over the fault in the |
|
Or at least, to clarify, the changes to the opam file aren't restoring compatibility for Dune 1.x - the changes to tests/sample.opam do! |
|
At the beginning, dune was restricted to |
|
Thanks, @rjbou - I wonder if it was the test, in that case! In which case, let's merge this and I'll separately work on the problem with the |
|
Thanks, @kit-ty-kate! |
|
Thanks @kit-ty-kate & @dra27! |
We're seeing failures on libraries when using dune 1.x. Notably in
dune-release.1.2.0:It fails with dune.1.6.2 and 1.9.3 but not with dune 2.0 (since it recompiles with dune itself)
This brings back the dune 1.0 compatibility so that everytime a package tried to compile
opam-file-formatusing dune,opam-file-formatitself will be compiled using dune.Currently the non-dune builds seems to not install the interface-only module:
OpamParserTypesand dune doesn't seem to like that.