I made kbuild 2.5 install very flexible to cater for cases like this.
The answer depends on whether you want every compile to be the same
with different install steps on the target machines or each compile is
different.
In the different compile case you have a single source tree (mounted
read only if you like) and separate object trees for each compile run.
The .config lives in the object directory so is machine local. The
object trees can be NFS mounted or can use local disk on each build
machine, as a bonus this avoids NFS writes and runs much faster.
If you want a common compile on one machine followed by different
installs on each machine then you have three choices.
(1) make install with an install prefix path (say /var/tmp) will
install the kernel, modules, System.map and .config in a holding
directory on the build machine, the other machines can then copy
the install data to wherever they need it. Whether the copy is
done from the build machine to the target directories or on the
target machine is an NFS implementation detail.
(2) make installable (the default target) on the build machine then run
make install with overrides on the target machines. All the
install config variables are exposed for override on the install
step.
(3) make installable on the build machine with .config specifying an
install script name. Then make install on each target system, the
version of the install script is local to the target machine.
If none of those suit your environment, let me know what you are trying
to achieve and I will see about adding support to kbuild 2.5.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/