On Wed, Jul 26, 2017 at 11:40:46AM +0300, Stas Sergeev wrote: > 26.07.2017 03:36, Jacob Keller пишет: > > If your goal is to make it so users filling out bug reports have a > > version, then using git descrsibe and making that be part of your > > version (based off your tags, and commits) is how pretty much every > > other project I've worked on does this. > > > > I really don't think that's your goal here, given you're doing things > > in make with timestamps and builds, so I guess I misunderstood your > > answer? > There are 2 different things: > 1. put git describe output into some header file > 2. make things to rebuild with every new commit > > So I actually stuck at solving 2, because 1 is trivial. > My original solution for 2 was to "depend" on > refs/heads/*. This worked besides git gc, but had > a lot of troubles with worktrees. And this time I > switched to the "touch tmpfile" trick with the date > taken from git log. This requires .LOW_RESOLUTION_TIME > in makefile, so probably not the best solution again, > but should hopefully be more future-proof than the > previous one. In git.git we do something like: -- >8 -- other: version cat $< >$@ .PHONY: FORCE version: FORCE @git rev-parse HEAD >$@+ @if cmp $@+ $@ >/dev/null 2>&1; then rm $@+; else mv $@+ $@; fi -- >8 -- The "version" commands run always, but they only update the file if there's a change. At least GNU make is smart enough to know that if "version" was not updated, then "other" does not need to be re-built. I don't know if all makes would so, though. -Peff