I think that all of these are limitations of not only make(1), but all utilities that expect dependencies to be fully known before a target is built. What makes you think they are not?
How would you solve all three problems I listed using make(1)?
How would you solve all three problems I listed using make(1)?
If I use pip as part of my buildchain, then it has a series of places it can lookup, or you can supply one. Same with npm, cargo, and even Go.
If instead, I use a tool that has dynamic lookup, then it will only look in those places after the event.
So, if I used make to send a command like:
$(echo 'require "foo"' > bar.lua)
So how would this be a limitation of make itself? The limitation only exists in what you call with make... Which could be anything.
By contrast, redo builds the target first and then records what was used to build it. For example, when compiling a C file with “gcc -M”, gcc will output dependency information. With redo, you normally record those dependencies after the target has been built. With make(1), that information has to end up in the makefile somehow, possibly leading to further builds.
From the manual, on implicit rules:
foo : foo.o bar.o cc -o foo foo.o bar.o $(CFLAGS) $(LDFLAGS)
Because you mention `foo.o' but do not give a rule for it, make will automatically look for an implicit rule that tells how to update it. This happens whether or not the file `foo.o' currently exists.