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.
# 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.
Last revised: Oct 2023
Problem
Current
scons installimplementation has a problem:scons installshould be called with exactly same options and arguments assconswas invoked earlier when building the project.Example from our cookbook:
The second scons invocation can't be just
sudo scons install. It should also have--enable-pulseaudio-modules --build-3rdparty=openfec,pulseaudiobecause these options were present in the first scons invocation.The reason is that internally,
scons installcreates an install target which depends on the build target, and the build target properties are defined by scons options and arguments. If you callscons installwith 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 installimplementation:build (default) target should copy final build results (executables, libraries) into
build/dist, in addition tobin/<host>;the file layout in
build/distshould match the installation layout, e.g. binaries should be copied tobuild/dist/bin, libraries tobuild/dist/lib, etc;scons installshould just copybuild/distinto the system; it should not depend on the build target;scons installshould check thatbuild/distactually has files to install.This way,
scons installwill 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 installto 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.