8000 Fix section in installed dune package by bobot · Pull Request #5404 · ocaml/dune · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Fix section in installed dune package #5404

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

Closed
wants to merge 2 commits into from

Conversation

bobot
Copy link
Collaborator
@bobot bobot commented Feb 1, 2022

Fix for #5394

@kit-ty-kate it is a revert of #4861 because dune-package must be substituted not just when dune-sites is used

bobot added 2 commits February 1, 2022 11:56
Signed-off-by: François Bobot <francois.bobot@cea.fr>
   Keep the additional tests. Sections are added in the dune-package not only
   when dune-site is activated

Signed-off-by: François Bobot <francois.bobot@cea.fr>
@bobot bobot requested a review from rgrinberg February 1, 2022 10:59
@kit-ty-kate
Copy link
Member

When is there more substitutions?

@bobot
Copy link
Collaborator Author
bobot commented Feb 1, 2022

I should not have used the term substitution. Replacement would be better. In the dune-package the local directory of the sections should be replaced by the installation destination for each section. All the sections of all the installed files are present.

@kit-ty-kate
Copy link
Member

I don’t get what this is about. Aren’t the sections relative to the root directory of the package?

@kit-ty-kate
Copy link
Member

If dune install should always be used, then all the opam packages in opam-repository would be wrong. Is that the case?

@bobot
Copy link
Collaborator Author
bobot commented Feb 1, 2022

What is the root directory of the package? share and lib are not in the same hierarchy in opam <switch>/share/<package>/ and <switch>/lib/<package>/... or in debian <switch>/share/ocaml/<package>/... and <switch>/lib/ocaml/<package>/....

If dune install should always be used, then all the opam packages in opam-repository would be wrong. Is that the case?

The problem appears only when using some advanced functionality, like dependency on file of a package. So it doesn't usually appear. When people will convert gradually to 3.0 and if they use the generated opam files, it will be solved.

(EDIT: I must admit that I'm perhaps wrong with the place where the dune package in debian installs files (principally regarding share) ).

(lang dune <version>)
(name a)
(sections
(lib
$TESTCASE_ROOT/_build/install/default/lib/a)
$TESTCASE_ROOT/a/_build/install/default/lib/a)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still don't see why are we using an absolute path here. We should be using a path relative to the dune-package file like we do every other path in dune-project.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can add the fix of #5394 in order to have relative path in _build/install, we can even have relative path in really installed dune-package (in opam switch or /usr). But in any case in really installed dune-package the path pointed must be the one where the files are installed, which is what this PR tackles.

@rgrinberg rgrinberg added this to the 3.0.0 milestone Feb 1, 2022
@rgrinberg rgrinberg added requires-team-discussion This topic requires a team discussion and removed requires-team-discussion This topic requires a team discussion labels Feb 1, 2022
@rgrinberg
Copy link
Member

@bobot do we still need this?

@bobot
Copy link
Collaborator Author
bobot commented Feb 10, 2022

No, I will close it.

@bobot bobot closed this Feb 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0