Meaning of project_root and workspace_root variables

[agarwal]

The documentation of the variables project_root and workspace_root is unclear to me. In a folder structure like this:

/home/me/big_project/
  dune-workspace
  sub_project/
    dune-project

I was hoping for:

• %{project_root} = /home/me/big_project/sub_project
• %{workspace_root} = /home/me/big_project

However, the actual values are:

• %{project_root} = ../..
• %{workspace_root} = ../../..

which is equivalent to:

• %{project_root} = /home/me/big_project/_build/default/sub_project
• %{workspace_root} = /home/me/big_project/_build/default

Is there any way to get the absolute paths to the source directories?

[rgrinberg]

Is there any way to get the absolute paths to the source directories?

There are intentionally no such paths. Accessing the source directories is considered to be bad practice and it risks breaking features such as multi context builds, source dir hygiene, and the --build-dir feature. Why do you need to access the source directory?

[rgrinberg]

I'm closing this as there are certainly no plans to compromise hygiene. Please let us know of concrete use cases and we'd be glad to consider them instead.

[agarwal]

The use case was to run a build command that depends on the output of running git. Regardless of whether you're in /home/me/_build/default or /home/me/_build/default/sub_project, any call to git ends up being based on /home/me/big_project/.git. But I also want /home/me/big_project/sub_project/.git to be relevant.

[rgrinberg]

Ah, but this is a bit problematic when shipping tarballs for example. It means that the rules will no longer work in that mode. So you do need something a little more clever than just depending on .git.

I've been considering to add a more general purpose git plugin for dune that would handle nuances such as this one. Which git calls are you doing? If it's just getting the commit information, why not use $ dune subst?

[agarwal]

Ah, but this is a bit problematic when shipping tarballs for example.

Right, our logic handles both cases, that the .git directory exists and that it doesn't. But the latter is actually hypothetical and we don't really need to support it. This is for internal code that is never released as a tarball.

why not use $ dune subst?

The issue we ran into with dune subst is that it requires us to do the substitution on every build because without the substitution your file contains watermarks that are not valid OCaml, e.g. %%VCS_COMMIT_ID%%. But in a multi-library dune workspace, we found this to impact our build times too much. Say this substitution is needed in lib1, but a developer is really working on lib7. Now they run dune build, and lib1 has to get rebuilt, and then lib2 which depends on it, ... all the way to lib7. For us, this led to incremental builds going from a few seconds to over 2 minutes. So it wasn't feasible.

So what we do now is put let commit = "none" in our code. Then, we depend on dune's profile. If the profile is dev (the default), we don't touch this file. It is valid OCaml and compiles. But in CI, when we do deployments, we set the profile to something else like prod, and then we do do the substitution.

[ghost]

@agarwal would the solution discussed in #1930 cover what you need? Since embedding versions inside executables is a common need, it seems like this is something that should be sorted once and for all in Dune directly.

[agarwal]

I think it might. I'm following that PR now and added a comment there.