The Buck daemon writes its port, process id, and log output to files in
a .buckd{sp} directory that the daemon creates in the
-project root directory. Subsequent Buck commands use these files to
+project root directory. Subsequent Buck commands use these files to
find the daemon process, and a new Buck daemon process will use
them to kill any already-existing daemon process.
It is safe to run multiple Buck daemons started from different project
-directories as they do not interfere with each other,
-making buckd suitable for use in shared-server environments
+directories as they do not interfere with each other,
+making buckd suitable for use in shared-server environments
or where several projects are being worked on concurrently.
While it runs, the Buck daemon process monitors the project's file
system and invalidates cached build rules if any build input files
-change. The Buck daemon excludes from monitoring any subtrees of the
+change. The Buck daemon excludes from monitoring any subtrees of the
project file system that are specified in
the {call buckconfig.project_ignore /} setting
-of .buckconfig. By adding project-specific output
-directories and source-control directories, such as.git, to
+of .buckconfig. By adding project-specific output
+directories and source-control directories, such as.git, to
this setting, you can significantly improve performance; this might be necessary
to avoid file-change overflows when using Buck daemons to build large
projects.
@@ -81,7 +81,7 @@ The Buck daemon process is killed if
-You can also kill the Buck daemon explicitly by
+You can also kill the Buck daemon explicitly by
running {call buck.cmd_kill /} in the directory tree for your project.
Note that if—for some reason—multiple instances of the
daemon are running, the buck kill command kills only one of
@@ -95,7 +95,7 @@ restarts.
-To disable the daemon and prevent it from starting, set the environment
+To disable the daemon and prevent it from starting, set the environment
variable {sp}NO_BUCKD to 1. For example:
If you change Buck's configuration, it invalidates any cached state
-stored by the Buck daemon—unless that change is to
-a small subset of configuration settings that are whitelisted
+stored by the Buck daemon—unless that change is to
+a small subset of configuration settings that are supported
in AbstractConfigIgnoredByDaemon.java.
{literal}
-Invalidating internal cached state:
-Buck configuration options changed between invocations.
+Invalidating internal cached state:
+Buck configuration options changed between invocations.
This may cause slower builds.
{/literal}
-Note that a Buck configuration change that invalidates the daemon's state can be
-caused not only by explicitly changing a setting in one of Buck's
-configuration files, such as .buckconfig or .buckconfig.local, but also by using
-the --config, --flagfile, or --config-file {call buck.cmd_link}{param name: 'common_parameters' /}{param rendered_text: ' command-line parameters' /}{/call}.
+Note that a Buck configuration change that invalidates the daemon's state can be
+caused not only by explicitly changing a setting in one of Buck's
+configuration files, such as .buckconfig or .buckconfig.local, but also by using
+the --config, --flagfile, or --config-file {call buck.cmd_link}{param name: 'common_parameters' /}{param rendered_text: ' command-line parameters' /}{/call}.
-Both attributes act as whitelists, with some exceptions. In general, if a target
+Both attributes act as allowlists, with some exceptions. In general, if a target
is not listed, there may be no dependency relationship. If
the within_view list is empty or unset, however, its check is
bypassed. Similarly, targets defined in the same build file always act as if