cumulative sum of column in datafile
Ah good, now I'm getting closer to what you need: a) under git, you want the timestamp of the last git commit, not caring about dates of local sources; b) out of git, you want a timestamp reflecting the latest changes to the code in the local sources (pls, confirm that's your intended behavior). As I think a) is already there, let's focus on b): you can't achieve that the way the Makefile.am is written now, because the timestamp is coming from: stat -c '%.10y' Makefile.am [...] @if cmp -s $@ $@t;...
"make" would fail if run outside of the git repository directory. So we ended up using the date instead. yeah, I'm seeing it in the commit [ef315e6f] by Henri, the part of supporting out-of-git tree make of the DEVELOPMENT_VERSION is preserved, as it is preserved the part that removed a direct Makefile dependency of timestamp.h from the .git/HEAD file. -git_current := $(shell cut -c6- $(top_srcdir)/.git/HEAD) -timestamp.h: $(top_srcdir)/.git/${git_current} Makefile +.PHONY: timestamp.h +timestamp.h:...
AFAIU, it is working fine, in that with DEVELOPMENT_VERSION version.c will include and depend on timestamp.h, which will be rebuilt by the Makefile rule fetching from git the timestamp. Just, it should not be .PHONY, it's a real file (not on repo), and its rebuild rule avoids overwriting it if the git timestamp does not change, thus once you remove the .PHONY, make does the right thing (attempt to rebuild timestamp.h, but ending up not updating it (if cmp -s ....), thus not following up on to rebuilding...
updated patch mentioning this bug# for extended info... https://sourceforge.net/u/kefren/gnuplot/ci/8db9fe2d58aba5317870f5ab843020fa27b5340a/
updated patch mentioning this bug# for extended info... https://sourceforge.net/u/kefren/gnuplot/ci/dd17d1599aeff2b714bb224d62d500c0ceb4c639/
avoid rebuild of gnuplot despite no changes
from some further diggings: version.c does have one peculiarity: it is the only source-code including timestamp.h: ~/gnuplot/src$ grep timestamp.h *.{c,h} version.c:#include "timestamp.h" I must be building with DEVELOPMENT_VERSION enabled, likely the problem cannot show up without that ~/gnuplot/src$ grep -A3 -B3 timestamp.h version.c const char gnuplot_version[] = "5.5"; const char gnuplot_patchlevel[] = "0"; #ifdef DEVELOPMENT_VERSION #include "timestamp.h" #else const char gnuplot_date[] = "2020-02-07...
from some further diggings: * version.c does have one peculiarity: it is the only source-code including timestamp.h: ~/gnuplot/src$ grep timestamp.h *.{c,h} version.c:#include "timestamp.h" I must be building with DEVELOPMENT_VERSION enabled, likely the problem cannot show up without that ~/gnuplot/src$ grep -A3 -B3 timestamp.h version.c const char gnuplot_version[] = "5.5"; const char gnuplot_patchlevel[] = "0"; #ifdef DEVELOPMENT_VERSION #include "timestamp.h" #else const char gnuplot_date[] =...
repo: https://github.com/gnuplot/gnuplot.git branch: master (commit: 7a547280) ~/gnuplot$ make [...] make[4]: Entering directory '/home/tommaso/gnuplot/src' Making timestamp.h depbase=`echo version.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ gcc -DHAVE_CONFIG_H -I. -I.. -I../term -I../term -DBINDIR=\"/usr/local/gnuplot-git/bin\" -DX11_DRIVER_DIR=\"/usr/local/gnuplot-git/libexec/gnuplot/5.5\" -DQT_DRIVER_DIR=\"/usr/local/gnuplot-git/libexec/gnuplot/5.5\" -DGNUPLOT_SHARE_DIR=\"/usr/local/gnuplot-git/share/gnuplot/5.5\"...
repo: https://github.com/gnuplot/gnuplot.git branch: master (commit: 7a547280) ~/gnuplot$ make [...] make[4]: Entering directory '/home/tommaso/gnuplot/src' Making timestamp.h depbase=`echo version.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ gcc -DHAVE_CONFIG_H -I. -I.. -I../term -I../term -DBINDIR=\"/usr/local/gnuplot-git/bin\" -DX11_DRIVER_DIR=\"/usr/local/gnuplot-git/libexec/gnuplot/5.5\" -DQT_DRIVER_DIR=\"/usr/local/gnuplot-git/libexec/gnuplot/5.5\" -DGNUPLOT_SHARE_DIR=\"/usr/local/gnuplot-git/share/gnuplot/5.5\"...
forgot: building git master tree, with GNU make 4.3, on Ubuntu 20.10.
make rebuilds version.o and relinks gnuplot despite no changes
bugfix for calling del_udv_by_name("FIT_COV_*", TRUE)
Great, and thanks for documenting the new function :-)!
I've updated/refreshed the modification, with a 2nd commit adding configure-time check for cbrt(), and falling back to an alternate implementation using pow() in case the function is not found. Very good observation about the ~/.gnuplot customization: my use-case derives mostly from the use of gnuplot for newbies. Personally, I've been using gnuplot over the last (20?) years in (almost all) my research papers, I'm a computer engineer, I can work-around any of my needs through scripting, UNIX piping,...
you're absolutely right, it was an arbitrary extension. All in all, it probably makes sense to keep it for real values only. I've just reflected that in the updated patch (setting undefined to TRUE and returning { not_a_value(), 0.0 } -- just guessing from some other code in standard.c, if there's a better way, pls, let me know). I like a lot that now I can easily plot cbrt(x) while the other way I get into the painful: plot x**(1.0/3.0) warning: Did you try to plot a complex-valued function? Thanks...
Please, merge this support for the cubic root (cbrt(), as per POSIX)