-
Notifications
You must be signed in to change notification settings - Fork 472
pkg: recognize default dune build commands #13592
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
Open
gridbugs
wants to merge
1
commit into
ocaml:main
Choose a base branch
from
gridbugs:dune-build-command-in-lockfiles
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
52 changes: 52 additions & 0 deletions
52
test/blackbox-tests/test-cases/pkg/lockfiles-dune-keyword.t
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,52 @@ | ||
| When Dune generates a lockfile for a package, if the package had the default | ||
| Dune build command, use the "dune" keyword in the lockfile rather than copying | ||
| its build command. | ||
|
|
||
| $ mkrepo | ||
| $ add_mock_repo_if_needed | ||
|
|
||
| $ mkpkg foo <<EOF | ||
| > build: [ | ||
| > ["dune" "subst"] {dev} | ||
| > [ | ||
| > "dune" | ||
| > "build" | ||
| > "-p" | ||
| > name | ||
| > "-j" | ||
| > jobs | ||
| > "@install" | ||
| > "@runtest" {with-test} | ||
| > "@doc" {with-doc} | ||
| > ] | ||
| > ] | ||
| > EOF | ||
|
|
||
| $ cat > dune-project <<EOF | ||
| > (lang dune 3.21) | ||
| > (package | ||
| > (name bar) | ||
| > (depends foo)) | ||
| > EOF | ||
|
|
||
| $ cat > bar.ml <<EOF | ||
| > let () = print_endline Foo.foo | ||
| > EOF | ||
|
|
||
| $ cat > dune <<EOF | ||
| > (executable | ||
| > (public_name bar) | ||
| > (libraries foo)) | ||
| > EOF | ||
|
|
||
| Lock, build, and run the executable in the project: | ||
| $ dune_pkg_lock_normalized | ||
| Solution for dune.lock: | ||
| - foo.0.0.1 | ||
|
|
||
| The lockfile contains the "dune" keyword rather than the build command: | ||
| $ cat dune.lock/foo.0.0.1.pkg | ||
| (version 0.0.1) | ||
|
|
||
| (build | ||
| (all_platforms ((dune)))) |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a bit too constraining. e.g. imagine a package removes
@docor sets-j 1then it doesn't trigger anymore.I would rather suggest parsing out whether there's a call to
dune build(and maybe potentially some infos about the targets but it doesn't have to be in this PR).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to me that the point of this PR is not to capture every dune invocation but only the default one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, my point is that this is very fragile and the PR would be a lot more valuable if it detected more cases. Otherwise the semantics are pretty hard to understand from a users perspective: a package can't just call
dune buildto be recognized as building with Dune, but it would need to exactly mirror the exact same, fairly complex and potentially over time changing incantation that dune generates (note that Dune used to generate different lines before). Also note that not all users use Dune to generate their opam files, so they might calldunein other ways, which then would not be recognized.In my opinion the starting point should be a specification of what we consider a "dune build", because there's a lot of questions from the top of my head that would need answering:
dune substrequired? Is it optional? Is it forbidden?dune buildfor sure, but which targets? Is@installrequired? Is@doc {with-doc}required, even if the package has no docs?./configurebeforedune buildstill a dune build? Iscp _build/default/install/bin/foo ${bin}/fooafterdune buildstill a valid dune build? Are there commands that are ok or commands that are forbidden?I think the answers to questions like these are important because that helps users to understand e.g. why their build is not a dune build and what they need to change to make it a dune build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The goal is to detect packages that could be built without shelling out, so we need to make sure that the build command would have had the same meaning as if Dune was to build the package internally. If a package builds with
dune build -j1for example, it's possible that it's not safe to build the package in parallel, so maybe Dune should still shell out in that case. Same for packages that run a configure script before building, or invokeduneindirectly (like from a Makefile).Perhaps a better alternative would be for dune to add a filed to opam files it generates indicating that the package can be built with dune's default command rather than having Dune attempt to parse the command and decide whether it's the default command?