Removing header files may lead to build failures (was: removing the last REQUIRES item from configuration.ccl leads to build failures)

[Roland Haas]

The underlying issue seems to be that changing configuration.ccl does not necessarily rebuild all files the were generated using information in it.

to reproduce:

1. get a fresh ET checkout (trunk will do)
2. add to `arrangements/EinsteinBase/CoordGauge/configuration.ccl`

REQUIRES Carpet

1. build Cactus
2. make sure that you have a file `configs/et/bindings/Configuration/Thorns/cctki_CoordGauge.h`. If such a file does not exists then most likely you did not start from a fresh checkout. touch the other .ccl files and src/Slicing.c in CoordGauge and build again. The file should appear. Make sure that `configs/et/build/CoordGauge/Slicing.c.d` contains `.../configs/et/bindings/include/../Configuration/Thorns/cctki_CoordGauge.h` if not, same as above.
3. remove the `REQUIRES` line you added
4. try to build Cactus
5. the build should fail with:

Checking status of thorn CoordGauge make[2]: * [make.checked] Error 2 make[1]: * [/data/rhaas/postdoc/gr/ET/configs/et/lib/libthorn_CoordGauge.a] Error 2 make: * [et] Error 2 If you make is the buggy version 3.81 then no reason is given. (make SILENT=no or make -d does not help you either)

If you are lucky and have a non buggy version of make (https://savannah.gnu.org/bugs/?15110#comment7) then it might actually tell you that it cannot find ` configs/et/bindings/Configuration/Thorns/cctki_CoordGauge.h`. To test this touch the file and try to build again. It should work now. Also Slicing.c.d will no longer contain a reference to the offending file.

A workaround is to not unlink `cctki_CoordGauge.h` in `lib/sbin/CreateConfigurationBindings.pl` around line 176. This generates an empty file which makes make happy.

To work around the buggy make (to get an error message) one can replace all

-include foo bar baz lines by

-include $(filter-out $(wildcard foo bar baz),foo bar baz)) include $(filter $(wildcard foo bar baz),foo bar baz)) ie use `-include` for non-existing files and `include` for existing ones.

The buggy make is what makes this hard, you don't know why the compilation fails and trying to force recompile of CoordGauge by touching any of its .ccl or source files does not help. I usually ended up doing a realclean. Very annoying if this happens on say Kraken.

Keyword:

[Erik Schnetter]

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.

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.

[Roland Haas]

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?

[Erik Schnetter]

I don't know how to force regenerating the dependency information if a file changed, unless (as we do at the moment) there is a make rule that states that the dependency information depends on the file. And this is what is currently breaking.

[Roland Haas]

Would two make runs work? First one to regenerate all possible dependency files, second one to actually build the executable. This has the downsides of (a) not being possible in the current make system (I believe) (b) being very slow on slow file systems.

Alternatively do you know of a way to output an error message when such a case is detected? Similar to the one about now deleting make.thorns and asking to rebuild?

[Erik Schnetter]

Two make invokations may work. Currently, there is one make invokation for the whole configuration, and one sub-make for each thorn. We would need two sub-makes per thorn, called one after the other (see file lib/make/make.configuration, line 209 where $(MAKE) is called. We would first call it with "deps" as target, then the way it is called currently. If the call to "deps" fails, we delete all dependency information in the thorn (rm -f *.d), and call "deps" again.