[ET Trac] [Einstein Toolkit] #767: removing the last REQUIRES item from configuration.ccl leads to build failures

[Einstein Toolkit]

#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?

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/767#comment:2>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit