X-Git-Url: http://www.git.cypherpunks.ru/?p=goredo.git;a=blobdiff_plain;f=README;h=a35eab3de85e5246da7c737de1718af811ba3109;hp=bfd862ecafecfb99dbf289733654517354eae20d;hb=14398260feaf14dac68b9bdb1c810ccba7d1e768;hpb=65e23fdc08df193588cb0c345b957806fffe9fe4 diff --git a/README b/README index bfd862e..a35eab3 100644 --- a/README +++ b/README @@ -9,28 +9,33 @@ apenwarr/redo (https://redo.readthedocs.io/en/latest/) were also implemented. Why yet another implementation? It is feature full and has better performance comparing to shell and Python implementation. +It passes tests from dieweltistgarnichtso.net's redo-sh.tests and +implementation-neutral from apenwarr/redo. + goredo is free software: see the file COPYING for copying conditions. Home page: http://www.goredo.cypherpunks.ru/ INSTALL *goredo-install* + +Hopefully it should work on all POSIX systems. > $ go get go.cypherpunks.ru/goredo $ goredo -symlinks $ export PATH=`pwd`:$PATH -If you have problems with *.golang.org's unability to verify +If you have problems with *.golang.org's inability to verify authenticity of go.cypherpunks.ru TLS connection, then you can disable their usage by setting GOPRIVATE=go.cypherpunks.ru. If you still have problems with the authenticity on your side, then build it manually: > $ git clone git://git.cypherpunks.ru/goredo.git $ cd goredo - $ git tag -v v0.4.0 + $ git tag -v v0.8.0 $ git clone git://git.cypherpunks.ru/gorecfile.git - $ ( cd gorecfile ; git tag -v v0.3.0 ) + $ ( cd gorecfile ; git tag -v v0.4.0 ) $ echo "replace go.cypherpunks.ru/recfile => `pwd`/gorecfile" >> go.mod $ git clone git://git.cypherpunks.ru/gotai64n.git - $ ( cd gotai64n ; git tag -v v0.1.0 ) + $ ( cd gotai64n ; git tag -v v0.2.0 ) $ echo "replace go.cypherpunks.ru/tai64n => `pwd`/gotai64n" >> go.mod $ go build $ ./goredo -symlinks @@ -41,12 +46,15 @@ NOTES *goredo-notes* * "all" target is default * stdout is always captured, but no target is created if it was empty * empty targets are considered always out of date -* .do's $3 is relative path to the file in same directory +* .do's $3 is relative path to the file in target directory * .do search goes up to / by default, but can be limited with either $REDO_TOP_DIR environment variable, or by having .redo/top file in it * target's completion messages are written after they finish * executable .do is run as is, non-executable is run with /bin/sh -e[x] -* tracing (-x) can be done only for non-executable .do +* tracing (-x) can be obviously done only for non-executable .do +* parallizable build is done only during redo-ifchange for human + convenience: you can globally enable REDO_JOBS, but still do for + example: redo htmls infos index upload FEATURES *goredo-features* @@ -68,9 +76,9 @@ FEATURES *goredo-features* * optional statusline with currently running/waiting/done jobs * target's stderr can be stored on the disk with TAI64N timestamp prefixes for each line. To convert them to localtime you can use either - tai64nlocal utility from daemontools (http://cr.yp.to/daemontools.html) - or make a symlink, to use built-in slower decoder: > - $ ln -s goredo tai64nlocal + tai64nlocal utility from daemontools (http://cr.yp.to/daemontools.html), + or similar one: > + $ go get go.cypherpunks.ru/tai64n/cmd/tai64nlocal COMMANDS *goredo-commands* @@ -96,6 +104,7 @@ COMMANDS *goredo-commands* default.do ../default.b.o.do ../default.o.do + ../default.do * redo-dot -- dependency DOT graph generator. For example to visualize your dependencies with GraphViz: > $ redo target [...] # to assure that **/.redo/*.dep are filled up @@ -138,14 +147,33 @@ goredo includes redo-stamp, that really records the stamp in the .dep file, but it does not play any role later. It is stayed just for compatibility. - Removed .do can lead to permanent errors of its non existence~ - -That is true, because dependency on it was recorded previously. Is it -safe to assume that .do-less target now is an ordinary source-file? I -have no confidence in such behaviour. So it is user's decision how to -deal with it, probably it was just his inaccuracy mistake. If you really -want to get rid of that dependency knowledge for foo/bar target, then -just remove foo/.redo/bar.dep. + Can removed .do lead to permanent errors of its non existence?~ + +Yes, because dependency on it was recorded previously. Is it safe to +assume that .do-less target now is an ordinary source-file? I have no +confidence in such behaviour. So it is user's decision how to deal with +it, probably it was just his inaccuracy mistake. If you really want to +get rid of that dependency knowledge for foo/bar target, then just +remove foo/.redo/bar.dep. + + Does redo-always always rebuilds target?~ + +goredo, together with apenwarr/redo, rebuilds target once per run. +Always rebuilds during every redo invocation, but only once during it +building. http://news.dieweltistgarnichtso.net/bin/redo-sh.html#why-built-twice +has other opinion, that is why its redo-sh.tests/always_rebuild_1 will +fail. Rebuilding of always-ed targets even during the same build process +ruins any redo's usability in practice. + +For example if my .h file contains source code's version number, that is +git-describe's output and all my other files depends on that header, +then any redo-ifchange of .o will lead to git-describe execution, that +is rather heavy. Of course, because of either hashing or possible +redo-stamp-ing its dependants won't be rebuilt further, but build time +will be already ruined. If you need to rebuild TeX documents (case +mentioned in redo-sh's FAQ) until all references and numbers are ready, +then you must naturally expectedly explicitly use while cycle in your +.do, as apenwarr/redo already suggests. STATE *goredo-state*