lix-project/lix-releng-staging
0
0
Fork 0
Code Packages Activity
lix-releng-staging/tests/build-hook.hook.sh

22 lines
332 B
Bash
Raw Normal View History

* The build hooks used to implement distributed builds can now be run in parallel. Hooks are more efficient: locks on output paths are only acquired when the hook says that it is willing to accept a build job. Hooks now work in two phases. First, they should first tell Nix whether they are willing to accept a job. Nix guarantuees that no two hooks will ever be in the first phase at the same time (this simplifies the implementation of hooks, since they don't have to perform locking (?)). Second, if they accept a job, they are then responsible for building it (on the remote system), and copying the result back. These can be run in parallel with other hooks and locally executed jobs. The implementation is a bit messy right now, though. * The directory `distributed' shows a (hacky) example of a hook that distributes build jobs over a set of machines listed in a configuration file.
2004-05-13 19:14:49 +00:00
#! /bin/sh
* Fix the build hook mechanism; pass the pointer graph to the hook.
2005-01-25 11:55:43 +00:00
#set -x
* An quick and dirty hack to support distributed builds.
2004-05-12 09:35:51 +00:00
* The build hooks used to implement distributed builds can now be run in parallel. Hooks are more efficient: locks on output paths are only acquired when the hook says that it is willing to accept a build job. Hooks now work in two phases. First, they should first tell Nix whether they are willing to accept a job. Nix guarantuees that no two hooks will ever be in the first phase at the same time (this simplifies the implementation of hooks, since they don't have to perform locking (?)). Second, if they accept a job, they are then responsible for building it (on the remote system), and copying the result back. These can be run in parallel with other hooks and locally executed jobs. The implementation is a bit messy right now, though. * The directory `distributed' shows a (hacky) example of a hook that distributes build jobs over a set of machines listed in a configuration file.
2004-05-13 19:14:49 +00:00
drv=$4
* An quick and dirty hack to support distributed builds.
2004-05-12 09:35:51 +00:00
* The build hooks used to implement distributed builds can now be run in parallel. Hooks are more efficient: locks on output paths are only acquired when the hook says that it is willing to accept a build job. Hooks now work in two phases. First, they should first tell Nix whether they are willing to accept a job. Nix guarantuees that no two hooks will ever be in the first phase at the same time (this simplifies the implementation of hooks, since they don't have to perform locking (?)). Second, if they accept a job, they are then responsible for building it (on the remote system), and copying the result back. These can be run in parallel with other hooks and locally executed jobs. The implementation is a bit messy right now, though. * The directory `distributed' shows a (hacky) example of a hook that distributes build jobs over a set of machines listed in a configuration file.
2004-05-13 19:14:49 +00:00
echo "HOOK for $drv" >&2
* An quick and dirty hack to support distributed builds.
2004-05-12 09:35:51 +00:00
* Fix the build hook mechanism; pass the pointer graph to the hook.
2005-01-25 11:55:43 +00:00
outPath=$(sed 's/Derive(\[("out",\"\([^\"]*\)\".*/\1/' $drv)
* An quick and dirty hack to support distributed builds.
2004-05-12 09:35:51 +00:00
* The build hooks used to implement distributed builds can now be run in parallel. Hooks are more efficient: locks on output paths are only acquired when the hook says that it is willing to accept a build job. Hooks now work in two phases. First, they should first tell Nix whether they are willing to accept a job. Nix guarantuees that no two hooks will ever be in the first phase at the same time (this simplifies the implementation of hooks, since they don't have to perform locking (?)). Second, if they accept a job, they are then responsible for building it (on the remote system), and copying the result back. These can be run in parallel with other hooks and locally executed jobs. The implementation is a bit messy right now, though. * The directory `distributed' shows a (hacky) example of a hook that distributes build jobs over a set of machines listed in a configuration file.
2004-05-13 19:14:49 +00:00
echo "output path is $outPath" >&2
* An quick and dirty hack to support distributed builds.
2004-05-12 09:35:51 +00:00
if $(echo $outPath | grep -q input-1); then
* The build hooks used to implement distributed builds can now be run in parallel. Hooks are more efficient: locks on output paths are only acquired when the hook says that it is willing to accept a build job. Hooks now work in two phases. First, they should first tell Nix whether they are willing to accept a job. Nix guarantuees that no two hooks will ever be in the first phase at the same time (this simplifies the implementation of hooks, since they don't have to perform locking (?)). Second, if they accept a job, they are then responsible for building it (on the remote system), and copying the result back. These can be run in parallel with other hooks and locally executed jobs. The implementation is a bit messy right now, though. * The directory `distributed' shows a (hacky) example of a hook that distributes build jobs over a set of machines listed in a configuration file.
2004-05-13 19:14:49 +00:00
echo "accept" >&3
read x <&4
echo "got $x"
* An quick and dirty hack to support distributed builds.
2004-05-12 09:35:51 +00:00
mkdir $outPath
echo "BAR" > $outPath/foo
* The build hooks used to implement distributed builds can now be run in parallel. Hooks are more efficient: locks on output paths are only acquired when the hook says that it is willing to accept a build job. Hooks now work in two phases. First, they should first tell Nix whether they are willing to accept a job. Nix guarantuees that no two hooks will ever be in the first phase at the same time (this simplifies the implementation of hooks, since they don't have to perform locking (?)). Second, if they accept a job, they are then responsible for building it (on the remote system), and copying the result back. These can be run in parallel with other hooks and locally executed jobs. The implementation is a bit messy right now, though. * The directory `distributed' shows a (hacky) example of a hook that distributes build jobs over a set of machines listed in a configuration file.
2004-05-13 19:14:49 +00:00
else
echo "decline" >&3
* An quick and dirty hack to support distributed builds.
2004-05-12 09:35:51 +00:00
fi
Copy permalink