public inbox for goredo-devel@lists.cypherpunks.ru
Atom feed
* possible double entry in targets list
@ 2023-01-14 18:02 ew.tmp2016
2023-01-14 18:06 ` ew.tmp2016
0 siblings, 1 reply; 3+ messages in thread
From: ew.tmp2016 @ 2023-01-14 18:02 UTC (permalink / raw)
To: goredo-devel
Hello,
I found a possibly wrong behaviour of goredo.
Consider the following setup:
- date.do is generating date, which holds a string presentation of the
current date/time. This item is considered to change /often/, i.e. on
every call to date.do, because I did include the seconds in the time
stamp.
- version.do is generating version, which holds a git hash or something
else. This item is regenerated always, but its content changes rarely.
- version.h.do is reading version.h.in (a template), date and version
as considered before, and generates a C header file from these two items.
So these files exist:
$ find . | LANG=C sort
.
./all.do
./date.do
./version.do
./version.h.do
./version.h.in
Now I call redo for the first time:
redo -xx
+ redo-ifchange version.h
+ redo-ifchange date version version.h.in
+ git rev-parse --short HEAD
+ redo-always
+ redo-stamp
redo . . version (0.005s)
+ date +%Y%m%d_%H%M%S
+ redo-always
+ redo-stamp
redo . . date (0.005s)
+ cat version
+ VERSION=3f26d30
+ cat date
+ DATE=20230114_184654
+ cat version.h.in
+ sed -e s/%%VERSION%%/3f26d30/g -e s/%%DATE%%/20230114_184654/g
+ redo-stamp
redo . version.h (0.036s)
redo all (0.046s)
This looks good.
Without any change I call redo again. I expect the file date to change,
and thus version.h to be rebuild.
$ redo -xx
+ git rev-parse --short HEAD
+ redo-always
+ redo-stamp
redo . version (0.006s)
+ date +%Y%m%d_%H%M%S
+ redo-always
+ redo-stamp
redo . date (0.005s)
+ redo-ifchange date version version.h.in
+ redo-ifchange date version version.h.in
+ cat version
+ VERSION=3f26d30
+ cat date
+ DATE=20230114_184812
+ cat version.h.in
+ sed -e s/%%VERSION%%/3f26d30/g -e s/%%DATE%%/20230114_184812/g
+ redo-stamp
redo . version.h (0.010s)
+ cat version
+ VERSION=3f26d30
+ cat date
+ DATE=20230114_184812
+ cat version.h.in
+ sed -e s/%%VERSION%%/3f26d30/g -e s/%%DATE%%/20230114_184812/g
+ redo-stamp
err . version.h (0.021s): $1 was explicitly touched
+ redo-ifchange version.h
redo all (0.003s)
This does happen, however, there is an error.
It seems to me that "version.h" is considered twice, because it is
dependent on two prerequisites (date and version), however, the second
entry is never cleared from the list.
I have tried to understand the situation with "-d all", but I'm not
good enough:
$ grep 'targets: ' xx1.good.log
[6870] dbg building 1 targets: [all]
[6880] dbg . building 1 targets: [version.h]
[6889] dbg . . building 3 targets: [version.h.in date version]
$ grep 'targets: ' xx2.bad.log
[6942] dbg . checking 2 dependant targets: [date version]
[6942] dbg . building 2 dependant targets: [version.h version.h]
[6985] dbg . . building 3 targets: [version.h.in date version]
[6993] dbg . . building 3 targets: [version version.h.in date]
[6942] dbg building 1 targets: [all]
[7023] dbg . building 1 targets: [version.h]
Please find the files I used listed below.
Thanks for providing goredo!
~ew
# ----------------------------------------------------------------------
# all.do -*-shell-script-*-
redo-ifchange version.h
# ----------------------------------------------------------------------
# version.do -*-shell-script-*-
git rev-parse --short HEAD > "$3"
redo-always
redo-stamp <"$3"
# ----------------------------------------------------------------------
# date.do -*-shell-script-*-
date +'%Y%m%d_%H%M%S' >"$3"
redo-always
redo-stamp <"$3"
# ----------------------------------------------------------------------
/* version.h.in -*-c-*- */
#ifndef __VERSION_H
#define __VERSION_H
#define PRJ_VERSION "%%VERSION%%"
#define PRJ_BLDDATE "%%DATE%%"
#endif // __VERSION_H
# ----------------------------------------------------------------------
# version.h.do -*-shell-script-*-
redo-ifchange date version version.h.in
VERSION=$(cat version)
DATE=$(cat date)
cat "$2".in |
sed -e "s/%%VERSION%%/${VERSION}/g" \
-e "s/%%DATE%%/${DATE}/g" \
> "$3"
redo-stamp <"$3"
# ----------------------------------------------------------------------
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: possible double entry in targets list
2023-01-14 18:02 possible double entry in targets list ew.tmp2016
@ 2023-01-14 18:06 ` ew.tmp2016
2023-01-17 9:17 ` Sergey Matveev
0 siblings, 1 reply; 3+ messages in thread
From: ew.tmp2016 @ 2023-01-14 18:06 UTC (permalink / raw)
To: goredo-devel
One more thing:
$ redo -version
goredo 1.28.0 built with go1.19.4
Thanks,
~ew.
Quoting ew.tmp2016@nassur•net:
> Hello,
>
> I found a possibly wrong behaviour of goredo.
>
> Consider the following setup:
>
> - date.do is generating date, which holds a string presentation of the
> current date/time. This item is considered to change /often/, i.e. on
> every call to date.do, because I did include the seconds in the time
> stamp.
>
> - version.do is generating version, which holds a git hash or something
> else. This item is regenerated always, but its content changes rarely.
>
> - version.h.do is reading version.h.in (a template), date and version
> as considered before, and generates a C header file from these two items.
>
> So these files exist:
> $ find . | LANG=C sort
> .
> ./all.do
> ./date.do
> ./version.do
> ./version.h.do
> ./version.h.in
>
> Now I call redo for the first time:
> redo -xx
> + redo-ifchange version.h
> + redo-ifchange date version version.h.in
> + git rev-parse --short HEAD
> + redo-always
> + redo-stamp
> redo . . version (0.005s)
> + date +%Y%m%d_%H%M%S
> + redo-always
> + redo-stamp
> redo . . date (0.005s)
> + cat version
> + VERSION=3f26d30
> + cat date
> + DATE=20230114_184654
> + cat version.h.in
> + sed -e s/%%VERSION%%/3f26d30/g -e s/%%DATE%%/20230114_184654/g
> + redo-stamp
> redo . version.h (0.036s)
> redo all (0.046s)
>
> This looks good.
>
> Without any change I call redo again. I expect the file date to change,
> and thus version.h to be rebuild.
>
> $ redo -xx
> + git rev-parse --short HEAD
> + redo-always
> + redo-stamp
> redo . version (0.006s)
> + date +%Y%m%d_%H%M%S
> + redo-always
> + redo-stamp
> redo . date (0.005s)
> + redo-ifchange date version version.h.in
> + redo-ifchange date version version.h.in
> + cat version
> + VERSION=3f26d30
> + cat date
> + DATE=20230114_184812
> + cat version.h.in
> + sed -e s/%%VERSION%%/3f26d30/g -e s/%%DATE%%/20230114_184812/g
> + redo-stamp
> redo . version.h (0.010s)
> + cat version
> + VERSION=3f26d30
> + cat date
> + DATE=20230114_184812
> + cat version.h.in
> + sed -e s/%%VERSION%%/3f26d30/g -e s/%%DATE%%/20230114_184812/g
> + redo-stamp
> err . version.h (0.021s): $1 was explicitly touched
> + redo-ifchange version.h
> redo all (0.003s)
>
>
> This does happen, however, there is an error.
>
> It seems to me that "version.h" is considered twice, because it is
> dependent on two prerequisites (date and version), however, the second
> entry is never cleared from the list.
>
> I have tried to understand the situation with "-d all", but I'm not
> good enough:
>
> $ grep 'targets: ' xx1.good.log
> [6870] dbg building 1 targets: [all]
> [6880] dbg . building 1 targets: [version.h]
> [6889] dbg . . building 3 targets: [version.h.in date version]
>
> $ grep 'targets: ' xx2.bad.log
> [6942] dbg . checking 2 dependant targets: [date version]
> [6942] dbg . building 2 dependant targets: [version.h version.h]
> [6985] dbg . . building 3 targets: [version.h.in date version]
> [6993] dbg . . building 3 targets: [version version.h.in date]
> [6942] dbg building 1 targets: [all]
> [7023] dbg . building 1 targets: [version.h]
>
>
> Please find the files I used listed below.
>
> Thanks for providing goredo!
> ~ew
>
> # ----------------------------------------------------------------------
> # all.do -*-shell-script-*-
> redo-ifchange version.h
> # ----------------------------------------------------------------------
> # version.do -*-shell-script-*-
>
> git rev-parse --short HEAD > "$3"
> redo-always
> redo-stamp <"$3"
> # ----------------------------------------------------------------------
> # date.do -*-shell-script-*-
>
> date +'%Y%m%d_%H%M%S' >"$3"
> redo-always
> redo-stamp <"$3"
> # ----------------------------------------------------------------------
> /* version.h.in -*-c-*- */
>
> #ifndef __VERSION_H
> #define __VERSION_H
>
> #define PRJ_VERSION "%%VERSION%%"
> #define PRJ_BLDDATE "%%DATE%%"
>
> #endif // __VERSION_H
> # ----------------------------------------------------------------------
> # version.h.do -*-shell-script-*-
>
> redo-ifchange date version version.h.in
>
> VERSION=$(cat version)
> DATE=$(cat date)
> cat "$2".in |
> sed -e "s/%%VERSION%%/${VERSION}/g" \
> -e "s/%%DATE%%/${DATE}/g" \
> > "$3"
> redo-stamp <"$3"
> # ----------------------------------------------------------------------
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: possible double entry in targets list
2023-01-14 18:06 ` ew.tmp2016
@ 2023-01-17 9:17 ` Sergey Matveev
0 siblings, 0 replies; 3+ messages in thread
From: Sergey Matveev @ 2023-01-17 9:17 UTC (permalink / raw)
To: goredo-devel
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
Greetings!
*** ew.tmp2016@nassur•net [2023-01-14 19:06]:
> I found a possibly wrong behaviour of goredo. [...]
Thank you very much! Indeed that was the bug, where is simultaneously
tried to run the same target by a single redo-process. That lead to the
found error. Fixed that in 1.29.0 release. And also thank you for the
provided .do-files that just moved to the test case conveniently.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-01-17 9:21 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-14 18:02 possible double entry in targets list ew.tmp2016
2023-01-14 18:06 ` ew.tmp2016
2023-01-17 9:17 ` Sergey Matveev