Pass client environment to persistent mode queries.

This CL removes NINJA_PERSISTENT_PASS_VARIABLES entirely.
Instead, the environment of the client process is always
passed as-is for each build query, and will be used to
spawn command processes only.

This reflects the exact behavior of incremental Ninja
build in non-persistent mode, and avoids having to
manager an allowlist or denylist of variables to pass.

This is rather large because this touches several parts
of the code at the same time:

- process_utils.h: Change the EnvironmentBlock
  implementation to support empty variables (unlike
  Windows, there is a difference between an unset
  and an empty variable on Posix).

- subprocess.h: Support passing an EnvironmentBlock
  to SubprocessSet, to use when spawning new
  command sub-processes.

- BuildConfig: Add an |environment| field, of type
  EnvironmentBlock, and provide methods to compute
  status_format() and others, replacing fields that
  were initialized by using getenv().

- build.cc: Ensure each build uses config.environment
  when launching commands.

- status.cc: Use the new accessors to get the status
  format, max commands count and refresh period.

- persistent_mode.cc: Remove special support for
  pass-through variables.

- persistent_mode_test.cc: Change the test query
  related to environment variables to probe the
  content of config.environment instead of using
  getenv(). Checking that the client environment
  variables are passed to spawned commands is
  now performed in an integration test (see below).

+ persistent_service.cc: Remove minor compiler
  warning.

+ output_test.py: Remove os.chdir() calls to avoid
  a FileNotFOundError at runtime when the current
  directory was left pointing to a now-deleted
  temporary directory. This only occured when
  running tests after the ones in output_test.py.

+ persistent_mode_test.py: Add a new integration
  test that verifies that persistent mode works
  properly!

Fuchsia-Topic: persistent-mode
Change-Id: Id5a3fa7f2d7595a0091029996809a2049e940c63
Reviewed-on: https://fuchsia-review.googlesource.com/c/third_party/github.com/ninja-build/ninja/+/933852
Reviewed-by: David Fang <fangism@google.com>
20 files changed
tree: f0aee7c368d3ec1c13dddcb2cc23e6ca0878e2e5
  1. .github/
  2. doc/
  3. misc/
  4. src/
  5. windows/
  6. .clang-format
  7. .clang-tidy
  8. .editorconfig
  9. .gitignore
  10. appveyor.yml
  11. CMakeLists.txt
  12. configure.py
  13. CONTRIBUTING.md
  14. COPYING
  15. README.fuchsia
  16. README.md
  17. RELEASING.md
README.md

Ninja

Ninja is a small build system with a focus on speed. https://ninja-build.org/

See the manual or doc/manual.asciidoc included in the distribution for background and more details.

Binaries for Linux, Mac and Windows are available on GitHub. Run ./ninja -h for Ninja help.

Installation is not necessary because the only required file is the resulting ninja binary. However, to enable features like Bash completion and Emacs and Vim editing modes, some files in misc/ must be copied to appropriate locations.

If you're interested in making changes to Ninja, read CONTRIBUTING.md first.

Building Ninja itself

You can either build Ninja via the custom generator script written in Python or via CMake. For more details see the wiki.

Python

./configure.py --bootstrap

This will generate the ninja binary and a build.ninja file you can now use to build Ninja with itself.

CMake

cmake -Bbuild-cmake
cmake --build build-cmake

The ninja binary will now be inside the build-cmake directory (you can choose any other name you like).

To run the unit tests:

./build-cmake/ninja_test