#767: removing the last REQUIRES item from configuration.ccl leads to build failures ---------------------+------------------------------------------------------ Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by rhaas):
Replying to [comment:1 eschnett]:
I believe this is not directly related to ccl file. I see the same
symptoms when I remove a header file, but have old dependency information (the auto-generated .d files) that still say this header file is required. In this case make fails with the strange message you list above.
I see. I had encountered the error a number of times but this was the first time that I could reproduce it.
The solution is to either remove the dependency files of the thorn in
question, or to use make *-cleandeps. After this, the build will work fine: the source tree is self-consistent, only the dependency information is outdated.
This is a bug in Cactus which generates the dependency information. This
dependency information is updated after reading the old dependency information, and updating relies on the outdated dependency information -- there is no way out. Luckily, header files are removed only rarely, so this is not a common symptom.
A solution could be to detect dependency errors that occur while
checking dependencies, and if so, try again. Or, if a source file was changed, we could recreate the dependency information, without checking the dependency information for whether the dependency information needs to be recreated... I believe this paragraph doesn't make sense unless you already understand what is going on.
That would seem to make sense and be in-line with the typical cause listed in the make bug report. If always regenerating the dependencies of a file when the file changes fixes this, then I would think that this is a good idea. At that point the file has to be read anyway (for compilation) so we are not slowing down the compile process very much on slow file systems.
Would this also make 'make' generate useful error messages or would one still have to use the double-include workaround to get error messages out of make 3.81?