Makefile: make 4.2.1 is not respecting Heads logic verification for already extracted packages

[tlaurion]

We can see the result here when a cache is restored without hacks:
https://app.circleci.com/pipelines/github/tlaurion/heads/293/workflows/e50cfc8b-c61f-474b-b2de-476e3cee845d/jobs/319/parallel-runs/0/steps/0-107

We see here that the build fails since make was already extracted there and the patch was already applied.
@osresearch ?

My hack was to delete that directory prior of building when qemu-coreboot was first built here, but it would be nice if make was also respecting Heads build system logic.

[tlaurion]

Applied fix here which fixes the issue until fixed under Heads buildsystem

[osresearch]

Is the cache being restored with the time stamps intact or are they all new? If a normal copy is done, then depending on the copy order, the $(build)/$(make_dir)/.patch file might be older than the patches/make-$(make_version).patch file, which leads to the patch attempt.

As a quick hack, the assumption could be made that make will never be re-patched in normal operation:

diff --git a/Makefile b/Makefile
index 084ad03..10faebf 100644
--- a/Makefile
+++ b/Makefile
@@ -602,8 +602,8 @@ $(build)/$(make_dir)/.extract: $(packages)/$(make_tar)
 	tar xf "$<" -C "$(build)"
 	touch "$@"
 
-$(build)/$(make_dir)/.patch: patches/make-$(make_version).patch $(build)/$(make_dir)/.extract
-	( cd "$(dir $@)" ; patch -p1 ) < "$<"
+$(build)/$(make_dir)/.patch: $(build)/$(make_dir)/.extract
+	( cd "$(dir $@)" ; patch -p1 ) < "patches/make-$(make_version).patch"
 	touch "$@"
 
 $(build)/$(make_dir)/.configured: $(build)/$(make_dir)/.patch

[tlaurion]

@osresearch : my concern here is that this module is the only one acting this way.

[osresearch]

The bootstrap make module is special; the other modules are handled by this logic: https://github.com/osresearch/heads/blob/master/Makefile#L269

Which both extracts and patches in one step, so that there is a clean-ish version of the tree when patch runs on it.