lix-releng-staging/tests/build-hook.hook.sh

#! /bin/sh

#set -x

while read x y drv rest; do

    echo "HOOK for $drv" >&2

    outPath=`sed 's/Derive(\[("out",\"\([^\"]*\)\".*/\1/' $drv`

    echo "output path is $outPath" >&2

    if `echo $outPath | grep -q input-1`; then
        echo "# accept" >&2
        read inputs
        read outputs
        mkdir $outPath
        echo "BAR" > $outPath/foo
    else
        echo "# decline" >&2
    fi

done
* 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
* Made the build hook mechanism more efficient. Rather than starting the hook every time we want to ask whether we can run a remote build (which can be very often), we now reuse a hook process for answering those queries until it accepts a build. So if there are N derivations to be built, at most N hooks will be started. 2010-08-25 20:44:28 +00:00			`while read x y drv rest; do`
* An quick and dirty hack to support distributed builds. 2004-05-12 09:35:51 +00:00
* Made the build hook mechanism more efficient. Rather than starting the hook every time we want to ask whether we can run a remote build (which can be very often), we now reuse a hook process for answering those queries until it accepts a build. So if there are N derivations to be built, at most N hooks will be started. 2010-08-25 20:44:28 +00:00			`echo "HOOK for $drv" >&2`
* An quick and dirty hack to support distributed builds. 2004-05-12 09:35:51 +00:00
* Made the build hook mechanism more efficient. Rather than starting the hook every time we want to ask whether we can run a remote build (which can be very often), we now reuse a hook process for answering those queries until it accepts a build. So if there are N derivations to be built, at most N hooks will be started. 2010-08-25 20:44:28 +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
* Made the build hook mechanism more efficient. Rather than starting the hook every time we want to ask whether we can run a remote build (which can be very often), we now reuse a hook process for answering those queries until it accepts a build. So if there are N derivations to be built, at most N hooks will be started. 2010-08-25 20:44:28 +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
* Made the build hook mechanism more efficient. Rather than starting the hook every time we want to ask whether we can run a remote build (which can be very often), we now reuse a hook process for answering those queries until it accepts a build. So if there are N derivations to be built, at most N hooks will be started. 2010-08-25 20:44:28 +00:00			if `echo $outPath \| grep -q input-1`; then
			`echo "# accept" >&2`
			`read inputs`
			`read outputs`
			`mkdir $outPath`
			`echo "BAR" > $outPath/foo`
			`else`
			`echo "# decline" >&2`
			`fi`

Fix tests So all these years I was totally deluded about the meaning of "set -e". You might think that it causes statements like "false && true" or "! true" to fail, but it doesn't... 2014-08-21 19:50:19 +00:00			`done`