Re: Generating missing depfiles by an automake based makefile
Dmitry Goncharov (10 February 2023 00:24) wrote: > When a depfile is missing (for any reason) the current automake > makefile creates a dummy depfile. This seems misguided. Better to include $(wildcard $(DEPFILES)) instead, so there are no misleading depfiles lying around to cause make to fail to make them when needed. As long as depfiles are created as a side-effect of creating the target they describe, absence of the depfile usually implies absence of that target, so there's no need to know what it depends on because you need to recreate it anyway. A more robust version of that is, taking the example of .o files as the targets, to EXTANT_OBJS := $(wildcard $(OBJECTS)) DEPFILES := $(EXTANT_OBJS:%.o=%.dep) include $(DEPFILES) so that if a target does exist, we do insist on regenerating its depfile, even if that means regenerating the target itself. We don't know the target's dependencies, so we don't know that it is up to date, so this isn't unreasonable, for all that it might turn out to have been up to date, after all. > From that point on the user has to notice that make is no longer > tracking dependencies and their build is incorrect. The issue here is creation of dummy depfiles. Don't Do That. Eddy.
Re: Generating missing depfiles by an automake based makefile
Dmitry Goncharov wrote: On Thursday, February 9, 2023, Tom Tromey wrote: It's been a long time since I worked on automake, but the dependency tracking in automake is designed not to need to rebuild or pre-build dep files. Doing that means invoking the compiler twice, which is slow. Instead, automake computes dependencies as a side effect of compilation. The hello.Po example presented above computes depfiles as a side effect of compilation. Moreover, when hello.Po is absent that makefile compiles hello.o as a side effect of hello.Po computation. In total there is only one compilation. What is the scenario where you both end up with an empty depfile and a compilation that isn't out of date for some other reason? That seems like it shouldn't be possible. When a depfile is missing (for any reason) the current automake makefile creates a dummy depfile. From that point on the user has to notice that make is no longer tracking dependencies and their build is incorrect. I am asking if automake can be enhanced to do something similar to hello.Po example above, in those cases when make supports that. If I understand correctly, the problem here is that the depfile is both empty and current. If Automake could set the dummy depfile's mtime to some appropriate past timestamp (maybe the Makefile itself?), it would appear out-of-date immediately and therefore be remade, also rebuilding the corresponding object. A quick check of the POSIX manual finds that touch(1) accepts the '-r' option to name a reference file and can create a file. Could we simply use "touch -r Makefile $DEPFILE" to create depfiles when we need dummies? -- Jacob
Re: Generating missing depfiles by an automake based makefile
I finally went back to the top of the thread. Dmitry> Here is a rule from an automake generated makefile. Dmitry> Below is a sample bash session with gnu make which demonstrates how a Dmitry> dummy shuffle.Po makefile fails to have shuffle.o rebuilt when Dmitry> shuffle.h changes. Dmitry> $ rm src/.deps/shuffle.Po Just don't do this. Maybe it's possible in theory to deal with this scenario, but it seems to me that it's not worth putting much effort into it. Tom
