Skip to content

Makefile: clean up set of executables to build

Romain requested to merge nomadic-labs/tezos:romain-makefile into master

Context

This MR is based on !6916 (merged).

This merge request continues the work started in !6871 (merged), with the goal of having only one source of truth for the set of executables to build and release. This particular MR focuses on the case where we build from source using make.

One Source of Truth

The main change is that we use script-inputs/released-executables and script-inputs/experimental-executables instead of listing executables manually in the Makefile.

As a consequence, we can remove sc_rollup_protocol_versions_without_number, so:

Closes #4194 (closed)

Parametric Build Target

Another change is that the build target is now parameterized by a variable (EXECUTABLES) which can be set when calling make. For instance:

make EXECUTABLES='octez-node octez-client'
make static EXECUTABLES=octez-node
make release EXECUTABLES="$(cat script-inputs/experimental-executables)"

This means that we can avoid copy-pasting the build job and yet still use it to build a set of executables that differs depending on the needs. This is used to update the main targets, and allows to avoid building unnecessary executables in scripts/ci/build_static_binaries.sh.

Experimental Executables

Currently on master the default target (i.e. running make) builds some experimental executables, in particular octez-baker-alpha, octez-accuser-alpha, octez-tx-rollup-node-alpha, etc. But octez-dal-node and octez-wasm-repl-alpha are only built by make build-unreleased. I believe that, for consistency, we want the default target to build either all experimental executables or none of them.

The argument to have make build no experimental executable is that users that build from source should get the same set of executables as they would get in Docker images, as static executables, and when installing with opam install octez. (Currently Docker images contain some experimental executables but it should not be the case except for master; fixing this will be the job of another MR.)

Arguments to have make build all experimental executables are:

  • it already builds most of them anyway, the only new executables would be octez-dal-node and octez-wasm-repl-alpha;
  • tests rely on those experimental executables being present at the root, and we already have a lot of confusion from devs who forget to run make build-unreleased, so if make no longer built octez-baker-alpha etc., it would be even worse.

So make building all experimental executables is the least disruptive change, both for devs and for users who actually want experimental executables. It does not mean that we cannot change this later, but the scope of this MR is to improve consistency and not to make the disruptive choice.

Dev Executables

There is a set of executables that are not useful for users and thus neither released nor experimental: octez-snoop and octez-protocol-compiler. Those executables are expected, by some tests, to be at the root after we run make.

Since the scope of this MR is to improve consistency and not to make disruptive choices, make still builds those executables.

Manually testing the MR

Remove the @ before dune build in the build target of the Makefile so that you can see the list of executables that is given to dune build. Then play with make:

# build everything with --profile dev
make
# build released executables with --profile release
make release
# build released and experimental executables with --profile release
make experimental-release
# build released executables with --profile static
make static
# build octez-node and octez-client with --profile dev
make EXECUTABLES='octez-node octez-client'

Checklist

  • Document any change to the user interface, including configuration parameters (see node configuration)
  • For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
  • Select suitable reviewers using the Reviewers field below.
  • Select as Assignee the next person who should take action on that MR
Edited by Romain

Merge request reports