`dune exec` should work with absolute paths
Desired Behavior
dune exec "$PWD/prog.exe"
This should build prog.exe and launch it
Current Behavior
$ cat prog.ml
let () = print_endline "hello world"
$ dune build
$ dune exec ./prog.exe
hello world
$ dune exec "$PWD/prog.exe"
Error: Program '/home/louis/demo/prog.exe' not found!
I suppose there's no reason why it shouldn't. PR's welcome.
I guess i can try this PR to start with :)
@rgrinberg just one doubt to confirm I read through the code and there seem to be context binded with the directory we work on(i guess thats why it was intended to work with relative paths). In case of this new feature which is responsible for the context?
I presume we should try to get the context of directory in which the actual file resides but please confirm if i am wrong
I guess this feature has some conflicts with existing design choices. It would nice if someone clarifies if it breaks the current ones :(
@Athishpranav2003 the simplest approach is to try mapping the absolute path to a relative path, relative to the workspace root, and then continue with the already-existing logic. I don't think there is much need to deal with contexts or the like. Cheers.
@nojb Seems like this works already - https://github.com/ocaml/dune/blame/main/bin/exec.ml#L229
@Khady i couldnt reproduce the issue, seems like absolute path is working for me
@Athishpranav2003 in your screenshot you are running dune exec $PWD/_build/default/bin/main.exe instead of dune exec $PWD/bin/main.exe
@nojb Seems like this works already - https://github.com/ocaml/dune/blame/main/bin/exec.ml#L229
If I understand correctly, this code allows to run an existing binary, for example dune exec /usr/bin/env.
@Khady can you give your dune config too for me to reproduce the issue
I've created an example of a repo https://github.com/Khady/dune-exec-abs-path
Ok now i am getting the problem
(° ͜ʖ͡°)╭∩╮=>dune clean Tue 27 Aug 2024 09:15:46 PM IST
~/p/dune-exec-abs-path
(° ͜ʖ͡°)╭∩╮=>dune build Tue 27 Aug 2024 09:16:02 PM IST
~/p/dune-exec-abs-path …
(° ͜ʖ͡°)╭∩╮=>dune exec ./demo.exe 180ms Tue 27 Aug 2024 09:16:09 PM IST
hello world
~/p/dune-exec-abs-path …
(° ͜ʖ͡°)╭∩╮=>ls Tue 27 Aug 2024 09:16:14 PM IST
_build/ demo.ml dune dune-project README.md
~/p/dune-exec-abs-path …
(° ͜ʖ͡°)╭∩╮=>tree Tue 27 Aug 2024 09:16:15 PM IST
.
├── _build
│ ├── default
│ │ ├── demo.exe
│ │ ├── demo.ml
│ │ └── demo.mli
│ └── log
├── demo.ml
├── dune
├── dune-project
└── README.md
3 directories, 8 files
So like its actually not running the binary in that relative path Thanks for @Khady I will take a look at this and prolly try to fix it(might need some time since i got stuck with other work)
Ok I'm going to argue that the issue is not just for dune exec but basically for the whole dune. For example dune ocaml top would benefit from better path handling too.
See for example https://discuss.ocaml.org/t/improved-toplevel-workflow-in-dune/10812/3 or
$ dune ocaml top /home/user/contrib/ocaml-ctypes/src/ctypes
Internal error, please report upstream including the contents of _build/log.
Description:
("Local.relative: received absolute path",
{ t = "default"; path = "/home/user/contrib/ocaml-ctypes/src/ctypes" })
Raised at Stdune__Code_error.raise in file
"otherlibs/stdune/src/code_error.ml", line 10, characters 30-62
Called from Stdune__Path.Local_gen.relative in file
"otherlibs/stdune/src/path.ml", line 130, characters 6-118
Called from Main__Top.term.(fun) in file "bin/ocaml/top.ml", line 53,
characters 10-73
Called from Fiber__Scheduler.exec in file "vendor/fiber/src/scheduler.ml",
line 76, characters 8-11
This will be fixed by #12094, I have crated a meta-issue for the other dune commands to aid with tracking.
- https://github.com/ocaml/dune/issues/12230