Makefile checknow
Hi, The Makefile contains a section called `check_now`. It references the files `zone1970.tab` and `zonenow.tab`. Other sections of the Makefile take account of the variable $ZONETABLES before using/checking zone files. Would it be possible to alter Makefile so it only runs check_now if at least one of zone1970/zonenow are in $ZONETABLES ? eg. something like this (now 100% sure this is the right logic...): check_now: checknow.awk date tzdata.zi zdump zic zone1970.tab zonenow.tab for tab in $(ZONETABLES); do \ rm -fr $@.dir mkdir $@.dir ./zic -d $@.dir tzdata.zi now=$(CHECK_NOW_TIMESTAMP) && \ future=`expr $(CHECK_NOW_FUTURE_SECS) + $$now` && \ ./zdump -i -t $$now,$$future \ $$(find $$PWD/$@.dir/????*/ -type f) \ >$@.dir/zdump.tab $(AWK) \ -v zdump_table=$@.dir/zdump.tab \ -f checknow.awk zonenow.tab rm -fr $@.dir done touch $@ thanks Stephen
On 2024-09-15 02:50, Stephen Colebourne via tz wrote:
The Makefile contains a section called `check_now`. It references the files `zone1970.tab` and `zonenow.tab`. Other sections of the Makefile take account of the variable $ZONETABLES before using/checking zone files. Would it be possible to alter Makefile so it only runs check_now if at least one of zone1970/zonenow are in $ZONETABLES ?
ZONETABLES is outside the Makefile section marked "macros that one plausibly might want to tailor". It'd be helpful to know why one would want to change its value, as that would likely affect more than just the now.ck rule. This reminds me of our October 2022 thread on a similar topic[1], which was addressed by adding a new target "check_mild". One way to address the current glitch might be to move now.ck from the "check_mild" to the "check" rule, as in the attached patch (which I have not installed). That way, one could run "make check_mild" to omit the test that fails when one changes ZONETABLES. Would that suffice? [1]: https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/JTCMY5DIGRN4PQNTYL...
On Sun, 15 Sept 2024 at 19:37, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2024-09-15 02:50, Stephen Colebourne via tz wrote:
The Makefile contains a section called `check_now`. It references the files `zone1970.tab` and `zonenow.tab`. Other sections of the Makefile take account of the variable $ZONETABLES before using/checking zone files. Would it be possible to alter Makefile so it only runs check_now if at least one of zone1970/zonenow are in $ZONETABLES ?
ZONETABLES is outside the Makefile section marked "macros that one plausibly might want to tailor". It'd be helpful to know why one would want to change its value, as that would likely affect more than just the now.ck rule.
This reminds me of our October 2022 thread on a similar topic[1], which was addressed by adding a new target "check_mild". One way to address the current glitch might be to move now.ck from the "check_mild" to the "check" rule, as in the attached patch (which I have not installed). That way, one could run "make check_mild" to omit the test that fails when one changes ZONETABLES. Would that suffice?
This is pretty much the same problem as 2022 - where Makefile has extended checks that don't meet the goals of global-tz. To me, ZONETABLES is a suitable solution as it explicitly states which zone* files are the ones that should be checked/processed. I currently run `make check VERSION="test" ZONETABLES="zone.tab"` I'm willing to change to `make check_mild VERSION="test" ZONETABLES="zone.tab"` if you want, although it seems like a worse outcome because ZONETABLES appears to have a clear definition which isn't currently being respected. Stephen
On 2024-09-15 13:19, Stephen Colebourne via tz wrote:
This is pretty much the same problem as 2022
OK, I installed the attached patch, which does the same sort of thing we did in 2022. I'd rather not worry about user tailoring of ZONETABLES as it's not currently designed to be tailored, there are too many other uses of the zone*.tab names in the Makefile, and trying to wrestle Makefile to allow arbitrary settings of ZONETABLES would be significantly more painful than the attached.
On Sun, 15 Sept 2024 at 23:19, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2024-09-15 13:19, Stephen Colebourne via tz wrote:
This is pretty much the same problem as 2022
OK, I installed the attached patch, which does the same sort of thing we did in 2022.
Thanks. This worked for me, and I was able to remove my hacky workaround. Stephen
participants (2)
-
Paul Eggert
-
Stephen Colebourne