Error while building navigator

[Rotoo]

Hello Damlers,

I’m trying to build DAML navigator using bazel and I got the following error:

bazel build //navigator/backend:navigator-binary_deploy.jar

No matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type. Maybe --incompatible_use_cc_configure_from_rules_cc has been flipped and there is no default C++ toolchain added in the WORKSPACE file?

I’m a scala newbie, so I might be missing something while building the project.

Thanks.

[stefanobaghino-da]

This is not really about Scala. I tried running the same command in my latest available main but I couldn’t reproduce the issue. Have you followed the instructions at step 2 here before running bazel?

[cocreature]

You can see in the error message that you’re using bazel 5.1.1, however the Bazel version included in our dev-env is 4.2.2 So @stefanobaghino-da’s suggestion is exactly right: You somehow haven’t activated dev-env properly and you’re getting a global Bazel installation instead.

[stefanobaghino-da]

To clarify: when working on Linux and macOS the repository relies on a package manager called Nix to maintain a consistent set of tools that ensures that every developer and CI have the same set of relevant packages installed, down to the exact version. We paired Nix with another tool called direnv, which automatically loads a set of environment variables when moving into a directory to create what we called dev-env, which basically activates Nix when in the repository.

Ultimately, rather than relying on software installed globally, you can cd into the repo, activate dev-env by following the instructions and let Nix do the rest and download the relevant artifacts.

If you are interested into understanding more about the tools I mentioned here are a few links:

• Nix: a package manager with features that enable to create reproducible environments
• direnv: load and unload environment variables when entering a directory
• dev-env: a basic template for a project that mixes of the two above to manage the environment automatically on a per-project basis

[Gary_Verhaegen]

It’s worth noting that, while dev-env works well enough in the daml repo that we don’t have any incentive to move away from it there, wee are no longer adding dev-env to new projects.

Instead, for new projects, we use direnv and nix (specifically nix-shell) more directly, in a way similar to the explanation in this blog post.

Since I’m often the one setting up new projects, I’ve made a small script for that:

$ cat ~/bin/init-nix 
#!/usr/bin/env bash

set -euo pipefail

if [ -f .envrc ] || [ -f shell.nix ] | [ -f .envrc.private ] || [ -d nix ]; then
  echo "Conflict detected. Not proceeding."
  exit 1
fi

cat <<EOF > .envrc
use nix

source_env_if_exists .envrc.private
EOF

cat <<EOF > shell.nix
# Update nixpkgs with:
# nix-shell -p niv --run "niv update"

let
  sources = import ./nix/sources.nix;
  pkgs = import sources.nixpkgs {};
in
pkgs.mkShell {
  buildInputs = [
    pkgs.bash
  ];
}
EOF

cat <<EOF > .envrc.private
# export MY_VAR="some value"
EOF

nix-shell -p niv --run "niv init -b nixpkgs-unstable"

[Rotoo]

Thank you all @stefanobaghino-da @cocreature @Gary_Verhaegen for your answers. They were very precise and detailed.

The problem resulted from the unconfigured dev-env