1. I find the syntax pretty offputting. 2. Make is found everywhere so a drop in replacement is a useful feature.
.FORCE:
.PRECIOUS: .sha256/sum/%
.sha256/tmp/%: % .sha256/tmp .FORCE
sha256sum < $< > $@
.sha256/sum/%: .sha256/tmp/% .sha256/sum
cmp $< $@ >/dev/null 2>&1 || mv $< $@
.sha256/tmp .sha256/sum:
mkdir -p $@
.SUFFIXES:
%.o: .sha256/sum/%.c
$(CC) $(CPPFLAGS) $(CFLAGS) -c -o $@ $*.c
It could use xattr to store its content tags.
And (self promotion) it is in my book: https://nostarch.com/gnumake (pg 82)
[1]: https://www.humblebundle.com/books/linux-no-starch-press-boo...
A criticism on this implementation: The "state" directory is never cleaned; new states are always added. Therefore if you go back to a state (hash) that you had already built in the past, you will not be able to build it again.
And there is no need to create separate shell scripts, when you can have all the relevant code inside your Makefile. Presumably those are not going to be called independently anyway.
As I've written on previous discussions:
Make by default uses the file change timestamp to trigger actions. But this is definitely not the only way, and you can code your Makefile so that rebuilds happen when a file's checksum changes. IIRC, the GNU Make Book has the code ready for you to study... Or, you might get more clever and say "when only a comment is changed, I don't want to rebuild"; file checksums are not the correct solution for this, so you can code another trigger.
Can you point to some documentation for this? I haven't been able to find anything.
I'm currently traveling, without access to my books, but a quick online search at the contents of this book https://nostarch.com/download/GNU_Make_dTOC.pdf shows that p.82 has the code for "Rebuilding When a File's Checksum Changes".
The GNU Make Book by John Graham-Cumming, No Starch Press, April 2015, 256 pp., ISBN-13: 978-1-59327-649-2
Having said that, there is definitely some work to do on keeping the remote storage somewhat clean.
This is not what the article is about, however,—it’s about building a build-input-addressable artifact cache that can be shared across machines, à la Bazel or Nix. (That Nix is a build system—and NixOS is a distro built on said build system, the same way that Gittup is built on Tup, the BSDs on Make, or Gentoo on its thing—seems to be a well-kept secret. The distinguishing idea that in that case “build artifact cache” = “binary repo” is brilliant, though.)
What I don’t get is what purpose Make serves in the context of the article: when the build process turns a whole bunch of files into one with no intermediate steps or separate compilation, it seems a plain shell script would do just as well as Make + auxiliary shell scripts. You could perhaps obtain some more structure (less strict source ordering?) with Make, but the article doesn’t seem to do that.
I wasn't sure whether including all that extra information in the post was worth it or not, so I hope this answers your question
Run all your scripts through https://www.shellcheck.net/ (you can install it locally too) and correct all errors it finds, click the explanation pages to understand why. In future, improve your style so you don't generate errors.
Here's some more I've found useful: - https://tldp.org/LDP/Bash-Beginners-Guide/html/index.html - https://tldp.org/LDP/abs/html/index.html
Also, do I need to include all of <a.h>'s includes, and of these includes' includes?
As someone who has recently developed a focused interest on build systems, I have noticed the large vacuum in the space for a content-based Make-like that has a similarly low of a barrier of entry. HN user bobsomers said it well the other day:
"There is a much tighter, cleaner, simpler build system within Bazel struggling to get out. A judicious second take at it with a minimal focus, while taking some of the best ideas, could be wildly successful I think."
https://news.ycombinator.com/item?id=32831890
I think 'redo' is probably the closest contender these days.
apenwarr's redo implementation is probably the most popular, the most mature, and has been built with a lot of smart design choices:
https://redo.readthedocs.io/en/latest/
Pluggable caching, which AFAIK apenwarr/redo does not yet support, would be a great addition, to support remote, shared caching.
make
# compiled foo.ts
vim foo.ts
make
# compiled foo.ts
git stash
make
# nothing to doThe main use case for this is ephemeral build hosts to share the cache, but I want to work all these issues out too, so thank you for the feedback
Wait what
| xargs -0 sha256sum \
- https://www.cmcrossroads.com/article/rebuilding-when-files-c... - http://olipratt.co.uk/rebuilding-makefile-targets-only-when-...