Conversation
I don't think we need to do anything about that. dune >= 2.0.0 binaries cannot read jbuild files at all, whether we are in a dune 1 or dune 2 project. |
ec3e63d to
3ad5b84
Compare
|
I have updated the list of breaking changes that the upgrader should take into account (first post). |
|
That looks all good to me! I can't think of anything else. Thanks! |
|
After performing some testing I encountered this change:
Which was not very clear in the changelog:
I will add that to the upgrader's work, and correct the doc/changelog. |
|
That's great! With |
0a6f52b to
e09db92
Compare
|
Ok, I think this PR is ready for review. All the logic is in
To update an old jbuild project to v2, the upgrader should be run twice. |
Is it difficult to make the tool sequence the upgrades automatically? it's not so important and I think that it probably makes sense for users to inspect each upgrade individually, but for some duniverse like use cases where you have a massive workspace of 3rd party packages, it would be annoying to run |
|
Yes I agree about this point, in particular that ensures that |
Ok so I tried to make the updater run twice in two ways:
In both cases it looks like the Any idea of how I could manage it ? |
|
Indeed the File_tree is not refreshed. However, this isn’t something that is too tough to fix.
If you look at File_tree.Settings.get, you will see that it depends on the current run. I suppose that we’d like for this to depend on a “ref” like value that we can control to reset the file tree after the upgrade finishes.
The only trick here is that we need this ref to respect memoization.
I’ve copied Arseniy. He can advise us if this is the best way to solve this problem.
…On Mar 5, 2020, 11:23 AM +0000, Ulysse ***@***.***>, wrote:
> Is it difficult to make the tool sequence the upgrades automatically?
Ok so I tried to make the updater run twice in two ways:
• Juste make it call itself recursively at the end of the first ugprade if v0-v1 upgrades where detected.
• Schedule two upgrades at the bin/upgrade.ml level
In both cases it looks like the File_tree is not refreshed: the second upgrades tries to perform v0->v1 upgrades again but fails because the jbuild files have already been translated and deleted.
Any idea of how I could manage it ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Thanks ! Is that a bad way to do it ? |
|
It’s not ideal but it should work as well in this case. The only negatives is that it could be confusing to future readers, and that it could possibly be slow things down. I think it’s fine to use here if you leave a comment why it’s necessary.
…On Mar 5, 2020, 12:39 PM +0000, Ulysse ***@***.***>, wrote:
Thanks, Memo has a reset function.
If I call this function before the new upgrading attempt it does work !
Is that a bad way to do it ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
I think calling |
|
Hello, Just checking in: what's the status of this? If it's doing the upgrades in an idempotent way I think it's good to go after a final round of review. |
|
I added a test illustrating the idempotency of the upgrade procedure. |
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
…3294) Signed-off-by: Ulysse Gérard <thevoodoos@gmail.com>
…lugin, dune-private-libs and dune-glob (2.5.0) CHANGES: - Add a `--release` option meaning the same as `-p` but without the package filtering. This is useful for custom `dune` invocation in opam files where we don't want `-p` (ocaml/dune#3260, @diml) - Fix a bug introduced in 2.4.0 causing `.bc` programs to be built with `-custom` by default (ocaml/dune#3269, fixes ocaml/dune#3262, @diml) - Allow contexts to be defined with local switches in workspace files (ocaml/dune#3265, fix ocaml/dune#3264, @rgrinberg) - Delay expansion errors until the rule is used to build something (ocaml/dune#3261, fix ocaml/dune#3252, @rgrinberg, @diml) - [coq] Support for theory dependencies and compositional builds using new field `(theories ...)` (ocaml/dune#2053, @ejgallego, @rgrinberg) - From now on, each version of a syntax extension must be explicitely tied to a minimum version of the dune language. Inconsistent versions in a `dune-project` will trigger a warning for version <=2.4 and an error for versions >2.4 of the dune language. (ocaml/dune#3270, fixes ocaml/dune#2957, @voodoos) - [coq] Bump coq lang version to 0.2. New coq features presented this release require this version of the coq lang. (ocaml/dune#3283, @ejgallego) - Prevent installation of public executables disabled using the `enabled_if` field. Installation will now simply skip such executables instead of raising an error. (ocaml/dune#3195, @voodoos) - `dune upgrade` will now try to upgrade projects using versions <2.0 to version 2.0 of the dune language. (ocaml/dune#3174, @voodoos) - Add a `top` command to integrate dune with any toplevel, not just utop. It is meant to be used with the new `#use_output` directive of OCaml 4.11 (ocaml/dune#2952, @mbernat, @diml) - Allow per-package `version` in generated `opam` files (ocaml/dune#3287, @toots) - [coq] Introduce the `coq.extraction` stanza. It can be used to extract OCaml sources (ocaml/dune#3299, fixes ocaml/dune#2178, @rgrinberg) - Load ppx rewriters in dune utop and add pps field to toplevel stanza. Ppx extensions will now be usable in the toplevel (ocaml/dune#3266, fixes ocaml/dune#346, @stephanieyou) - Add a `(subdir ..)` stanza to allow evaluating stanzas in sub directories. (ocaml/dune#3268, @rgrinberg) - Fix a bug preventing one from running inline tests in multiple modes (ocaml/dune#3352, @diml) - Allow the use of the `%{profile}` variable in the `enabled_if` field of the library stanza. (ocaml/dune#3344, @mrmr1993) - Allow the use of `%{ocaml_version}` variable in `enabled_if` field of the library stanza. (ocaml/dune#3339, @voodoos) - Fix dune build freezing on MacOS when cache is enabled. (ocaml/dune#3249, fixes #ocaml/dune#2973, @artempyanykh)
This PR aims to track the ongoing development of a new procedure that would help users to upgrade their projects to
dune_lang >=2.0. The hope is that a vast majority of projects can be migrated in a mostly automated way. After the upgrade users will be prompted with a list of hard-to-migrate things that they should check manually.Progression
Doc updates
self_build_stubs_archivedoes not exists since 2.0c_names/c_flags/ etc do not exist since 2.0Breaking changes that should be automatically handled
relies on the version written in the
dune-projectfile and nolonger read
VERSIONor similar files.actionfield in thealiasstanza is not available startinglang dune 2.0. Thealiasfield in therulestanza is a replacement.(formatting)stanza indune-project.💡 The upgrader adds
(formatting disabled)when the project was not formatted. It adds(formatted (enabled_for ...))when needed.modesfield of executables to(mode exe). Ifone wants to build a bytecode program, it now needs to be explicitly
requested via
(modes byte exe). *💡 The upgrader adds
(modes byte exe)to executables without explicit mode.preprocessor_depsfield is present but notpreprocessfield is. It is a warning with Dune 1.x projects.💡 The upgrader removes
preprocessor_depsfield when there is nopreprocessfield or if the chosen preprocess isno_preprocessingno_keep_locsis a no-op for projects that uselang duneolder than 2.0. Inprojects where the language is at least
2.0, the field is now forbidden.Note: this feature has been subsequently extended into a separate foreign_stubs field.
💡 In libraries and executables stanzas, the upgrader replaces the fields
c(xx)_namesandc(xx)_flagsby an appropriateforeign_stubsfield.Breaking changes that the user should be aware of
Drop support forjbuildandjbuild-ignorefiles.warning and is now an error. *
self_build_stubs_archivewas deleted in version 2.0 of the dune languageocaml-syntax-shimsbinary. In order to usefuture_syntax, one now need to depend on theocaml-syntax-shimspackage.
preprocessing) are now an error instead of a warning.
ocaml-syntax-shimsbinary. In order to usefuture_syntax, one now need to depend on theocaml-syntax-shimspackage.
<package>.installfiles in the source tree unless-por--promote-install-filesis passed on the command linewould be allowed for unwrapped libraries
select. The file names of conditionalsources must match the prefix and the extension of the resultant filename.
now be actual modules.
and is now an error.
(diff? x y)action, requirexto exist and register adependency on that file.
Non-breaking changes