KBEA-00129 - Using the parse avoidance feature

ElectricAccelerator includes a parse avoidance feature, which can effectively eliminate makefile parse time in many builds. By caching and reusing parse result files, Accelerator can speed up both full builds and incremental builds.

Parse avoidance works when emulating GNU Make with clusters and/or local agents (such as with ElectricAccelerator Developer Edition).

Parse avoidance uses the concept of cache "slots." When parse avoidance is enabled, Electric Make (eMake) maintains a slot for each combination of non-ignored command line options, non-ignored environment variable assignments, and the current working directory. (Ignored command line options and environment variables are listed below.) A slot can be empty or can hold a previously-cached result. If the appropriate slot holds an up-to-date result, parsing is avoided.

If eMake detects file system changes that might have caused a different result (with the same command line options, environment variable assignments, and current working directory), a cached result becomes obsolete. Such file system changes include any file read by the parse job, which means all makefiles, all programs invoked by $(shell), the files they read, and so on.

When a cached parse result is reused, eMake replays the file system modifications made during the parse job and any standard output or standard error that the original parse job produced. For example, if the makefile includes the following lines:

then when using a cached parse result, eMake creates a file named myfile and prints Warning: updated myfile.

You must first run a "learning" build with the parse avoidance feature enabled. To enable parse avoidance, use the --emake-parse-avoidance=1 eMake option.

During the learning build, the option causes eMake to save the parse result to the (empty) cache. For subsequent builds, the option enables the reuse of cached parse results and saves a new result to the cache as appropriate. If you do not specify --emake-parse-avoidance=1, then the parse avoidance cache is not accessed at all.

The following actions are also recommended:

The following table describes options related to parse avoidance.

|== | eMake Option | Description

| --emake-assetdir=<`path>` | Use the specified directory for assets such as cached parse results. The default directory is .emake. This option also affects dependency optimization.

| --emake-parse-avoidance=<`0/1>` | Avoid parsing makefiles when prior parse results remain up to date. Cache new parse results when appropriate.

| --emake-parse-avoidance-ignore-env=<`var>` | Ignore the named environment variable when searching for applicable cached parse results. To ignore more than one variable, use this option multiple times.

| --emake-parse-avoidance-ignore-path=<`path>` | Ignore this file or directory when checking whether cached parse results are up to date. Append % for prefix matching. To ignore more than one path or prefix, use this option multiple times.

| --emake-suppress-include=<`pattern> ` | Skip matching makefile includes (such as generated dependencies). In general, you should not suppress makefile includes, unless they are generated dependency files and you have also enabled automatic dependencies as an alternative way of handling dependencies. Note: If the pattern does not have a directory separator, then the pattern is compared to the include’s filename component only. If the pattern has a directory separator, then the pattern is taken relative to the same working directory that applies to the include directive and compared to the included file’s entire path. |==

If a file is read during a parse, but it changes before eMake attempts to reuse that parse’s results, the cached parse result is normally considered to be obsolete. You can, however, override this decision temporarily by using --emake-parse-avoidance-ignore-path.

eMake permanently ignores the effect on a parse result of certain special files and directories that might have existed when it was created, in all cases using the names they would have had at that time:

Notes:

You can use a pragma to instruct parse avoidance to detect the dependence of a parse result upon path wildcard match results. This pragma makes the parse cache sensitive to the existence (or nonexistence) of specific files in directories that are subject to wildcard matching, as well as in new subdirectories thereof. (eMake does not detect matching files in just any new subdirectory, but only those that are subdirectories of directories read in the original job and their subdirectories, recursively.)

You can specify more than one glob pattern, as in the following pragma:

For Android-specific information about parse avoidance and other Android best practices, see KB article KBEA-00130 at KBEA-00130 - Best Practices for Android Builds Using CloudBees Build Acceleration 10.0 and Older Versions.

This example provides command line options for Android 4.1.1 (using the attached makefile):

To delete the cache, delete <`assetdir>/cache.. (The default asset directory is `.emake.) For example, enter rm -r .emake/cache.

If you want to move your workspace, make sure that the new eMake roots correspond to the old eMake roots. Also, because the asset directory defaults to .emake in the current working directory, you must either copy that directory to the new workspace or use --emake-assetdir= to specify an asset directory that you want the two workspaces to share. If you already use --emake-assetdir= to point to an asset directory within your old workspace and also want to move the asset directory, you must update its value to point to the new asset directory location.

eMake looks for eMake roots in the values of Make variables. When eMake replays a cached parse result in a new workspace, it replaces the old eMake roots in the values of those variables with the new eMake roots. This policy works well as long as no confusion exists between eMake roots and other text in those variable values. For example, if the value of a Make variable is -I/we will look into this, your old eMake root is /we, and your new eMake root is /wg, then the new value will be -I/wg will look into this. For best results, choose distinctive directory names for your workspaces.

To log information about parse avoidance, enable parse avoidance debug logging. You do this by including a capital "P" in the argument of the --emake-debug=<`value>` option to set the parse avoidance debug log level. For more information about debug logging, see the "Troubleshooting" chapter of the ElectricAccelerator Electric Make Users Guide at https://docs.cloudbees.com/docs/cloudbees-build-acceleration/latest/emake-user-guide/troubleshooting.

You can look in "P" debug logging for an explanation of why a cached result was obsolete:

Notice that "Makefile" and "fog.mk" were both larger; either of those changes would have triggered a re-parse. The "ignore:0" comments indicate that --emake-parse-avoidance-ignore-path was not used to ignore the changes.

To discover why a new cache slot was used, look in the "P" debug logging for the name of the "key" file for that new cache slot; for example:

Then diff that key file against other key files in sibling directories to see which parameters changed. To determine which slot directories to compare, grep for the parse job IDs in "P" debug logging. You can get parse job IDs from annotation using ElectricInsight. Each key file contains an artificial "cd" command to express the working directory, all non-ignored environment variables, and the non-ignored command-line arguments.

Ignored command-line arguments and environment variables are omitted from key files. The key file is stored in a directory whose path name is derived from the MD5 digest of the file itself, which you can compute using the "md5sum" program. Also, the command line might have been normalized to one that is equivalent to the original one. eMake quotes special characters according to UNIX, Linux, or Cygwin "sh" shell rules.