Desired Behavior
During the running dune build, dune can respond to ^D signal and exit the execution as soon.
Currently, it seems to ignore it until finish initial scanning, which is slow if the sub-directory contain dune-related files.
The issue is suggested by @jeremiedimino for reminding in this OCaml Discuss post.
He suggests: insert checkpoint to check for signals during the initial scan.
Pressing ^C several time quickly can perform an emergency exit (just knowing this), and I suggest:
removing dune-project file if there is no one before running dune build.
Example
The original topic in the post is on how dune should behave when there is no dune-project or dune-workspace. A pain point scenario is assuming you have directories where code is just a path for containing true dune projects.
code
|-----pj1 (a dune project)
|-----pj2 (another unrelated dune project)
Occasionally, you might run dune build at path code rather than at code\pj1. you realize it's a wrong action but dune is beginning initializing process.
Desired Behavior
During the running
dune build, dune can respond to ^D signal and exit the execution as soon.Currently, it seems to ignore it until finish initial scanning, which is slow if the sub-directory contain dune-related files.
The issue is suggested by @jeremiedimino for reminding in this OCaml Discuss post.
He suggests: insert checkpoint to check for signals during the initial scan.
Pressing ^C several time quickly can perform an emergency exit (just knowing this), and I suggest:
removing
dune-projectfile if there is no one before runningdune build.Example
The original topic in the post is on how dune should behave when there is no
dune-projectordune-workspace. A pain point scenario is assuming you have directories wherecodeis just a path for containing true dune projects.Occasionally, you might run
dune buildat pathcoderather than atcode\pj1. you realize it's a wrong action but dune is beginning initializing process.