Follow-up Comment #6, bug #58734 (project make): > I forgot to mention, that this happens in parallel and in serial mode. So your assumption is wrong.
I said, running the command twice can only happen with parallel builds enabled. I stand behind that statement as correct. I was careful to make a distinction between that and the problem of files not existing. > 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. I explained this but just realized that message went to the mailing list, not to the bug: If you want parallel builds to work correctly you _must_ "introduce unneeded files". This is a deficiency in the POSIX standard (it does not provide any way to explain to make that a single invocation of a recipe generates multiple output files) and if you want to write portable makefiles that will also work properly with parallelism enabled then there's no other way to solve that problem. _As a result of_ introducing the hidden files to fix the parallel builds issue, that _will also_ fix the caching problem. In short, if you ensure that your makefile works properly with parallel builds then you won't have a caching problem. This is why the caching problem is not a huge issue for every user: virtually every GNU make user these days enables parallel mode, and they want their makefile to work properly with it. > 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. The only purpose of the cache is reducing the number of stat() calls make has to do. Obviously once make determines that a target is already up to date, it doesn't have to check it again. If you say that for all other files make should always re-check, then there's no reason to cache. If you're saying something different, such as as long as make has not run a command that might possibly change some timestamp that it can cache the mod time ... well ... that's pretty much exactly what I said in my list of possible enhancements (again this went to the mailing list unfortunately). > Time stamp checking is also faster than re-running a command for a related rule. Of course! But it's not faster than not checking the timestamp in the first place, which is what the directory cache is for. If your makefile describes the target and prerequisite relationships completely, without omitting any relevant information, then the directory cache provides performance improvements. If you don't, then it can do the wrong thing. As I've written already, it's clear from experience that some makefiles don't provide sufficient information and the cache should be modified to address that. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?58734> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/