Cluster hosts must be able to execute all tools (compilers, linkers, and so on) required during the build. Three execution setup choices:
-
Tools are available on the cluster in the same locations as on the host build system —this is the simplest setup and requires no special eMake or build system configuration.
This is the most common setup if tools are provided from a network mount (for example, an NFS or SMB server). If tools are not supplied from a network share, but are installed on the local disk on each host, those tools must be updated whenever tools on the build system change.
-
Tools are available on the cluster, but not necessarily in the same locations as the host build system —this configuration is common in environments where users are allowed to install tools on their host system in non-standard locations.
In this case, care must be taken to ensure build steps executing on the hosts find the tools. Usually, this means making the PATH
environment variable include standard locations used on the cluster hosts—any other variables referencing tool locations need to be modified similarly.
As in the first case, if tools are installed on the cluster hosts’ local disk, they must be updated when tools are updated on the host system.
-
Tools are not installed on the cluster —in this case, when no tools are installed on the cluster,
EMAKE_ROOT
is configured to include the tools directory so the compiler and linker are sent to the Agents by eMake [in the same manner as the source files].
This is the most flexible setup because it eliminates the need to install or update tools on the hosts. If tools change frequently or vary between branches, this setup can dramatically reduce setup cost. However, to gain this flexibility, you typically trade performance because network overhead is increased.
Another factor to consider is the possibility that configuration information for a virtualized tool might not work on the host. For example, it is not possible to virtualize the Microsoft Visual Studio IDE because of its tight integration with the local machine’s registry.
In some special cases, it might be necessary to use tools outside of the virtualized file system. To support running such tools on the local build machine during a cluster build, you can use the CloudBees Build Acceleration proxyCmd
command. For details, see Using the Proxy Command.
CloudBees does not recommend the CloudBees Build Acceleration proxyCmd command for frequent use; use it with caution.
|