Rework scons install target

[gavv]

Last revised: Oct 2023

Problem

Current scons install implementation has a problem: scons install should be called with exactly same options and arguments as scons was invoked earlier when building the project.

Example from our cookbook:

# build libraries and tools
$ scons -Q --build-3rdparty=libuv,libatomic_ops,openfec

# install libraries and tools
$ sudo scons -Q --build-3rdparty=libuv,libatomic_ops,openfec install

The second scons invocation can't be just sudo scons install. It should also have --enable-pulseaudio-modules --build-3rdparty=openfec,pulseaudio because these options were present in the first scons invocation.

The reason is that internally, scons install creates an install target which depends on the build target, and the build target properties are defined by scons options and arguments. If you call scons install with options, it'll decide that the build target is not up-to-date, since it was previously built with other properties, and will try to rebuild it, with empty options (and will likely fail or at least build something other than the user wants).

Solution

Rework scons install implementation:

• build (default) target should copy final build results (executables, libraries) into build/dist, in addition to bin/<host>;

• the file layout in build/dist should match the installation layout, e.g. binaries should be copied to build/dist/bin, libraries to build/dist/lib, etc;

• scons install should just copy build/dist into the system; it should not depend on the build target;

• scons install should check that build/dist actually has files to install.

This way, scons install will just install results of the last build, without trying to build anything by itself.

Additional changes

We should also update our user cookbook after implementing this.

It would be nice to add scons install to our CI scripts. Currently this functionality is not covered by CI.

Info

Search for "AddDistFile" and "AddDistAction" in the source code.

Unfortunately, our scons internal are not documented. Discussions in PR #347 may give some hints.