[bug #58734] gmake does not check for the existence of a file before complaining it is missing

[Paul D. Smith]

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/