Dune build error

Learning
1

Hi, I am new to Ocaml, and follow this tutorial, try a helloworld , run dune build, it doesn’t work as I expected.

image
image1020×282 11.3 KB

dune version: 3.0.2
ocaml: 4.11.1
How can I solve this?

1 Like
2

Are you sure that you ran dune init exe helloworld fist as in the tutorial? If you did, and you still get this error, then it could be a bug in dune 3.00. (Dune 3.0 strengthened the rules about dune-project, but dune init should support the new rules!)

3

This has already been solved on SO: Ocaml: dune build eror? - Stack Overflow

2 Likes
4

Well I don’t think it was “solved” on SO, given that the problem persists that a high-visibility tutorial has instructions that broke with the Dune 3.0 release. We need the Dune people to fix their software (or the tutorial to be fixed, but in this case I think the tutorial is right), otherwise many other beginners are going to run into this issue.

2 Likes
5

Note: @douyu did report the issue to Dune upstream and in fact it was already reported independently two days ago. The Dune developers are already aware of it, and hopefully they will fix dune init shortly.

1 Like
6

The tutorial is wrong, at least since the dune devs decided to remove automatic generation of dune-project files it has been invalidated. But dune init exec has never been the right way to initialize projects. See Project initalized with `init exec` does not build (cannot find root) · Issue #5460 · ocaml/dune · GitHub for some details.

It’s maybe also worth noting here the exact problem, and the way to fix it, and a link to the docs with further details are all included in the error message which is included in the screenshot here :slight_smile:

7

Here’s the fix for the tutorial: Fix "Up and running" tutorial by shonfeder · Pull Request #325 · ocaml/ocaml.org · GitHub

1 Like
8

I disagree, I think that it’s a pretty natural assumption that dune init ... commands will result in a working Dune build, and that UI changes that break this property need to be fixed.

My completely uninformed guess is that the current 3.0 behavior is the result of unforeseen interactions between independent UI decisions, and not an intentional choice. I hope that Dune will add tests to check that the documented workflow works in the future.

I find the UI suggestions you made in a wizard / quickstart a la oasis would be cool · Issue #159 · ocaml/dune · GitHub excellent and I think they are better than what we have today (dune init or dune new should create a new build system, and “adding a component” should be a separate command).

But now I think the tool should follow the principle of last surprise, and ensure that dune init commands correctly initialize the build system. (There are now three issues on the Dune repository complaining about this, so users are definitely surprised in a bad way.)

This is precisely what you asked for in `dune init project` is broken due to project/workspace root detection · Issue #4960 · ocaml/dune · GitHub , but for all dune init commands. Note that the behavior you reported before your issue was marked resolved is actually better (if you replace dune init proj in the message by touch dune-project or whatever) than the “current” behavior of succeeding silently in this case, because at least it tells users clearly what they should do to fix the problem.

$ dune init proj foo
Error: I cannot find the root of the current workspace/project.
If you would like to create a new dune project, you can type:

    dune init project NAME

Otherwise, please make sure to run dune inside an existing project or
workspace. For more information about how dune identifies the root of the
current workspace/project, please refer to
https://dune.readthedocs.io/en/stable/usage.html#finding-the-root
4 Likes
9

I think that it’s a pretty natural assumption that dune init ... commands will result in a working Dune build

That is a natural assumption, but it’s an incorrect assumption.

I find the UI suggestions you made in a wizard / quickstart a la oasis would be cool · Issue #159 · ocaml/dune · GitHub excellent and I think they are better than what we have today ( dune init or dune new should create a new build system, and “adding a component” should be a separate command).

I agree with you! (I am also the person who did the work to implement dune init the way it is, because it was the – imo, unfortunate – way the core maintainers insisted it be done). If users would like to see an improved UI, they should submit a feature request for it. But the current behavior is actually working as intended.

But now I think the tool should follow the principle of last surprise, and ensure that dune init commands correctly initialize the build system. (There are now three issues on the Dune repository complaining about this, so users are definitely surprised in a bad way.)

This would break the current design around component-wise initialization, since you couldn’t dune init exec foo to create a new executable in the current directory without either also creating a dune-project file in that directory (this is incorrect behavior if you’re only adding a new library), or searching up to find the parent dune-project file of the project. But what if it doesn’t find one? How would init then know where the root of the project was supposed to be?

Note that the behavior you reported before your issue was marked resolved is actually better (if you replace dune init proj in the message by touch dune-project or whatever) than the “current” behavior of succeeding silently in this case, because at least it tells users clearly what they should do to fix the problem.

Again, this comes from a misunderstanding about the way dune init works. This is a design/UI bug, and IMO the only way to fix it is to ask the core maintainers to support a more conventional and user friendly interface around project initialization.

1 Like
10

I guess dune init {exec,lib,test} could be changed to fail loudly when run outside of the context of a dune project? Maybe that would help a bit.

Honestly, I still think the right way forward is to add a new subcommand which just has the functionality of dune init proj (and maybe deprecate everything else in the init subcommand. I’d be surprised if any of the component initialization stuff gets used).

1 Like
11

Also, to clarify one last point, `dune init project` is broken due to project/workspace root detection · Issue #4960 · ocaml/dune · GitHub was not about the failure to create dune-project files. That issue was opened after dune init proj was fixed to generate the dune-project files, but resulted from subsequent breakage coming from interaction of incorrectly eager root detection logic.

12

The current behavior may be following the original intention of the maintainers, but it surprises users and wastes their time so it is wrong! If there is a reasonable fix that preserves backward-compatibility and behaves as user expect, it should be applied.

Dune has logic to find the project root. dune init <component> should look at whether there is a project root. If there is, it can behave as dune add. If there is not, then there are two choices:

  1. Complain about the user that they are not using the tool as intended and they probably want to run dune init project first if they want a quickstart wizard or carefully place a dune-project file somewhere if they intend to be in a subdirectory.
  2. Create a dune-project file in the current directory, and explicitly let the user know about this so that they can delete if if they intended to already be inside a dune project.

Option (2) corresponds exactly to what dune build was doing on before 3.x. I think it was the wrong UI choice for dune build, because it is easy to unintentionally run dune build (or dune clean or whatever) outside a dune project. It may be the right UI choice for dune init that users interpret as initializing a project.

This being said: I’m taking your point that dune init currently has a bad UI and we should discourage users from using it. It’s not just that dune init exe is weird, even dune init project does not seem to have the right behavior for quick-starting a Dune project, at least with my local dune 2.9 (this is exactly the issue @yminsky reported at "dune init project" doesn't create a dune project file, creates unnecessary _build file · Issue #5429 · ocaml/dune · GitHub ).

3 Likes
13

I replied on that issue: this was a bug introduced on 2.9 by premature introduction of the change that stopped generation of dune-project files. It is fixed with the new release. See: "dune init project" doesn't create a dune project file, creates unnecessary _build file · Issue #5429 · ocaml/dune · GitHub

I can see the rationale for the behavior of dune init <component> you suggest. But hopefully fixing the documentation and directing users to upgrade to dune 3 will help as a stopgap until the maintainers and devs figure out how they want to fix the tool.

My own energy reserves for contributing to this feature are long past spent.

14

FWIW, this surprised me and wasted my time just yesterday.

CLI tools, CL arguments, configuration files using unintuitive home-baked structures that keep changing are ok if you’re a pro using it every day but it is bad for beginners and casual users. I can never remember the correct incantations for any of OCaml’s tools. Repeatedly changing them for no reason makes matters worse.

1 Like
15

Note: I hope I didn’t come across as criticizing you or your work. I think it’s great that more people contribute to Dune, especially with usability in mind. I was strong-worded here because I think that this is a case of “should we fix the spec we wrote, or the imaginary spec that the user has in mind?” where the current behavior probably needs fixing, and know that it can be harder to tell for people very familiar with the current code and spec.

Thanks for your contributions!

2 Likes
16

I appreciate your consideration and encouragement. But my frustration and lack of energy isn’t a reaction to your critiques here.[1]

I don’t have the political authority to make the changes that would improve the UX around this. But I hope others will have better luck.

afaict, the main reason for this incorrect spec in user’s minds is the highly visible tutorial that was instructing users on incorrect usage[2]. So, while the UI is definitely not ideal, imo this seems to be at least partially a problem of misinformation.

[1]: My frustration is due to me feeling responsible for a feature which has has not turned out as I hoped, and keeps getting broken, and the lack of energy is due to being a purely volunteer contributor whose primary interests are not in CLI interfaces.
[2]: It is not even consistent with other documentation on the same site (see ocaml.org/01_bootstrap_project.md at 5e6174ca3fd106c8bf4baf8286ac775ddb0b0a85 · ocaml/ocaml.org · GitHub)

2 Likes
17

This is completely off-topic but, FWIW, I’ve had enormous success hosting a language in the browser using Monaco as the editor (the editing component of VSCode) in a wiki precisely because it side steps all of the problems with VCSs, build systems, package managers, IDEs and so on. If anyone is looking for a project, I highly recommend hosting OCaml in the browser in this way.