tup monitor (tries to) build in a loop upon failure
uohmak4fvpqe opened this issue · 8 comments
This has been the case for quite a while for me, so I'm a bit surprised.
Just built from master on clearlinux
To reproduce, launch tup monitor -f, or with tup monitor and the option foreground = 1 in .tup/options (both tested);
Then (or before), introduce any syntax error on the code and save.
From now on and until the code is compilable again, it will try to build again without waiting for file changes, cluttering the terminal and making impossible to read the output.
Hope this can be fixed soon as the feature is life changing for me
Thanks for the report! I assume you also mean with autoupdate set, so the monitor is triggering tup to build, right? Is it autoupdating constantly without you touching anything? Or is it autoupdating as you continue to edit your files?
I tried this with vim and ran the monitor with 'tup monitor -a -f -d' (autoupdate, foreground, debugging on). Vim appears to be writing to a .swp file on every change to the file, which triggers the autoupdate build without saving the file.
It looks like this changed with commit e3d4a32 - previously, tup used to ignore all files starting with '.', but that was changed in e5b0b37. The monitor was later updated to be consistent with the rest of tup. Presumably for convenience, the monitor should have a way to skip those files for autoupdate purposes.
Can you confirm that this is what you are seeing? Or is it truly stuck in an infinite loop of autoupdates?
Thanks for the quick reply
this is my .tup/options file :
[display]
color = always
job_numbers = 0
job_time = 1
progress = 1
[monitor]
autoupdate = 1 ######
foreground = 1
[updater]
keep_going = 1
Is is autoupdating without touching anything until the file is compilable again.
I also reproduce using tup monitor -a -f -d.
For the dot files things; Well I don't use vim. I checked gedit and I think it doesn't do that either (auto backups are disabled).
Here's a fragment of the output :
Initialized in 0.021956 seconds.
[monitor:997065 ../src/tup/monitor/inotify.c:571] E[1: 32]: 'db-journal' 00000200 [1, 2]
[monitor:997065 ../src/tup/monitor/inotify.c:571] E[2: 16]: '' 00000020 [1, 2]
[monitor:997065 ../src/tup/monitor/inotify.c:804] Flush[0]: mem=0 events_handled=0
[monitor:997065 ../src/tup/monitor/inotify.c:632] monitor off
[monitor:997065 ../src/tup/monitor/inotify.c:571] e[1: 32]: 'db-journal' 00000200 [1, 2]
[ tup ] [0.000s] No filesystem scan - monitor is running.
[ tup ] [0.000s] No tup.config changes (environment check disabled).
[ tup ] [0.000s] No Tupfiles to parse.
[ tup ] [0.000s] No files to delete.
[ tup ] [0.001s] Executing Commands...
[ ] 0%[monitor:997065 ../src/tup/monitor/inotify.c:571] e[46: 32]: 'main.cc.o' 00000040 [1, 2]
[monitor:997065 ../src/tup/monitor/inotify.c:771] Queue[32]: 46, 'main.cc.o' 00000040
[monitor:997065 ../src/tup/monitor/inotify.c:571] e[28: 32]: 'main.cc.o' 00000040 [1, 2]
[monitor:997065 ../src/tup/monitor/inotify.c:771] Queue[32]: 28, 'main.cc.o' 00000040
[monitor:997065 ../src/tup/monitor/inotify.c:571] e[28: 32]: 'main.cc.o' 00000080 [1, 2]
[monitor:997065 ../src/tup/monitor/inotify.c:771] Queue[32]: 28, 'main.cc.o' 00000002
* [build-release] src: ../../build-release/src/main.cc.o
main.cc: In lambda function:
main.cc:56:26: error: expected primary-expression before '...' token
56 | try {...
| ^~~
*** tup messages ***
*** Command ID=5300 failed with return value 1
[ ] 43%[monitor:997065 ../src/tup/monitor/inotify.c:571] e[46: 32]: 'main.cc.o' 00000080 [1, 2]
[monitor:997065 ../src/tup/monitor/inotify.c:771] Queue[32]: 46, 'main.cc.o' 00000002
* [build-debug] src: ../../build-debug/src/main.cc.o
main.cc: In lambda function:
main.cc:56:26: error: expected primary-expression before '...' token
56 | try {...
| ^~~
Ok I just found that the problem appears when using ^o ^ in the rules.
Ok I just found that the problem appears when using
^o ^in the rules.
Thanks for discovering the connection to ^o - that was hugely helpful. I think this should be fixed with 6a542ac - can you try the latest master and see if it is working as you expect now?
Ok I just found that the problem appears when using
^o ^in the rules.Thanks for discovering the connection to ^o - that was hugely helpful. I think this should be fixed with 6a542ac - can you try the latest master and see if it is working as you expect now?
It does seem to be fixed 👍
thank you
There is a serious regression :
If a new target fails to compile, tup (monitor or not) now fails with the following error instead of showing gcc/clang error report:
[ ] 0%tup error: Unable to lstat() output './build-debug-native-gnu/pro/src/main.cc.o' after restoring it.
The only way to unlock that situation seems to effectively make the code compilable a first time (for instance by making the function dummy the time of compiling again).
This is very problematic if you happen to reintroduce a previously retired but correct source into the codebase, but it not fails for a reason hard to guess
There is a serious regression :
If a new target fails to compile, tup (monitor or not) now fails with the following error instead of showing gcc/clang error report:
[ ] 0%tup error: Unable to lstat() output './build-debug-native-gnu/pro/src/main.cc.o' after restoring it.
Ugh, sorry about that. I think commit 15306e2 should address this. Thanks for reporting it!
ok, seems fine now