Follow-up Comment #5, bug #58734 (project make): I forgot to mention, that this happens in parallel and in serial mode. So your assumption is wrong.
Caching is not a bad thing if it helps to speed up things. I did not make related tests and I am not going to doubt here because this would put effort on the wrong target. I am also not going to add unneeded hidden files when there is already a file that is created as a result of the command that has been run. The main problem for this bug is that gmake does not implement the cache the right way. If you like to use caching the right way, you may do so whenever this caching contains information that leads to the assumption that a target is up to date. The gmake command failed not because of caching in general but because of the fact that gmake does not correct invalid cache content. Please keep in mind that the current implementation of gmake causes gmake to stop working with a wrong error message. If you run gmake again, it works further on, up to the next similar problem while other make implementations just continue to work with the first call. This behavior of gmake is annoying and slows down the compilation. It would be so easy just to re-check the time stamp of every cached file that is believed to be out of date or missing. Time stamp checking is also faster than re-running a command for a related rule. A time stamp in "make" may have three values (the last one is a range): - File dos not exist. This may become invalid if cached. - Younger than any file. This will never become invalid for the lifetime of make. - A specific time stamp. This may become invalid and rechecking is faster than running a command again. In special as only the time stamp of a single file needs to be checked in such a case. Just a note: I've seen commands that have been run twice as a result of not verifying the third case in gmake. BTW: some of the problems I have with gmake would go away if there was not an unlucky combination of contradictory behavior. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?58734> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/