The eMake executable is called emake. The most important change to your build process is to ensure this executable is invoked in place of the existing Make.
For interactive command-line use, ensure the following:
-
The CloudBees Build Acceleration ` bin` directory is in your
PATHenvironment variable: -
For Linux:
<install_dir>/i686_Linux/bin(/opt/ecloud/i686_Linux/binby default) or<install_dir>/i686_Linux/64/bin(/opt/ecloud/i686_Linux/64/binby default) -
For Windows:
<install_dir>\i686_win32\bin(C:\ecloud\i686_win32\binby default) or<install_dir>\i686_win32\64\bin(C:\ecloud\i686_win32\64\binby default) -
You type
emakein place of gmake or nmake.
| The 64-bit version of eMake is recommended for builds with very large memory requirements. |
You can rename the eMake executable to either gmake or nmake, because eMake checks the executable to determine which emulation to use. If the name of the submake is hard-coded in many places within your makefiles, a simple solution would be to rename gmake or nmake to gmake.old or nmake.old, and rename eMake to either gmake or nmake on cluster hosts only. In this way, you can maintain access to your existing make, but all submakes from an CloudBees Build Acceleration build will correctly use eMake.
CloudBees does not recommend running builds in /tmp.
|
To ensure eMake is called for recursive submake invocations in makefiles, use the $(MAKE) macro for specifying submakes instead of hard-coding references to the tool. For example, instead of using:
libs: make -C lib
use the following $(MAKE) macro:
libs: $(MAKE) -C lib
Single Make invocation
It is important to keep the build in a single Make invocation. At many sites, Make is not directly invoked to do a build. Instead, a wrapper script or harness is used to invoke Make, and users (or other scripts) invoke this wrapper. The wrapper script might take its own arguments and might perform both special set up or tear down (checking out sources, setting environment variables, post-processing errors, and so on). Because eMake behaves almost exactly like native Make tools, usually it can directly replace the existing makefile in wrapper scripts.
Sometimes, however, the script might invoke more than one Make instance. For example, the script could iterate over project subdirectories or build different product variants. In this case, each of these builds becomes a separate CloudBees Build Acceleration build, with its own build ID, Cluster Manager entry, history file, and so on.
It is much more efficient for Make instances that are logically part of one build to be grouped under the control of a single parent Make invocation. In this way, eMake can track dependencies between submakes, ensure maximal parallelization and file caching, and manage the build as a single, cohesive unit.
If your build script invokes more than one submake, consider reorganizing makefile targets so a single Make is invoked that in turn calls Make recursively for submakes.
If a lot of the setup for each instance occurs within the build script, another possible solution is to use a simple top level makefile to wrap the build script; for example,
all: my-build-harness ...
In this instance, my-build-harness runs on the Agent much like any other command and sends commands discovered by submake stubs back to the host build machine. This approach works only if each submake’s output is not directly read by the script between Make invocations. Otherwise, it might be susceptible to submake stub output problems. See Submake Stubs for more information.