Skip to content
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

[DOCUMENTATION][IMPROVEMENT] Runtest vs compilation #11217

Open
SnarkBoojum opened this issue Dec 16, 2024 · 6 comments
Open

[DOCUMENTATION][IMPROVEMENT] Runtest vs compilation #11217

SnarkBoojum opened this issue Dec 16, 2024 · 6 comments
Labels
docs Documentation improvements

Comments

@SnarkBoojum
Copy link

This is about this discussion on zulip.

I had a situation where a library and an executable were built, and then that executable was run against various files to get Coq files, which were then compiled using Coq to check everything was ok.

The compilation part should have been: lib+exec, and the runtest part should have been: run exec, compare output, compile Coq file.

I had a hard time preventing running the Coq file at the compilation stage, and hence running exec at the compilation stage, although I was using some code to change the default target.

It turns out it was a documentation issue: it's not in the tests/ directory one should do something about the default target, but in the above directory. The toplevel dune file had to do:

(alias (name default)
       (deps (alias_rec bin/all)
             (alias_rec lib/all)))

in order to avoid executing everything in the tests/ directory.

@maiste maiste added the docs Documentation improvements label Dec 16, 2024
@maiste
Copy link
Collaborator

maiste commented Dec 16, 2024

Thanks for reporting! Indeed, it might be interesting to add somewhere that as test are executable and dune build would build them by default as it is always present. Maybe the default page should highlight more how the implication of the alias_rec all.

@rgrinberg I'm curious here, what is the reason why dune build also build the tests targets? Is it because we consider it a general build?

@Alizter
Copy link
Collaborator

Alizter commented Dec 17, 2024

dune build is just dune build @@deafult and the default alias defaults to recursively depending on all in subdirectories so everything is built.

@maiste
Copy link
Collaborator

maiste commented Dec 17, 2024

@Alizter thanks for the answer. Sorry, my question was ambiguous! I was wondering what is the reason behind attaching all to default including tests? I'm asking because, for example, in Golang, if you run go build it won't try to build the tests. The tests would only be built when running go test. I'm wondering why this behavior was chosen for Dune.

@Alizter
Copy link
Collaborator

Alizter commented Dec 17, 2024

@maiste Here is the original design discussion:

I think the decision mostly comes from a place of "what is the easiest set of defaults so that most users build what they want". Having @default not include tests was deemed more confusing hence the switch to the current situation. At least from what I can tell.

@Alizter
Copy link
Collaborator

Alizter commented Dec 17, 2024

So the alias default meaning all by default empirically makes the most users happy. The fact that it can be fine tuned to others needs by overriding the default alias allows for the unhappy to improve their situations.

@maiste
Copy link
Collaborator

maiste commented Dec 17, 2024

Oh, I see. Indeed, it makes sense to define the default as what most users want.
Thanks for having taken the time digging PRs and the explanations! 😄

The improvement mentioned in this issue should lend in the https://dune.readthedocs.io/en/stable/reference/aliases/default.html page or in a How-to-guide like "How to change the behavior of the @default alias".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation improvements
Projects
None yet
Development

No branches or pull requests

3 participants