Re: toolchain/34934

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR bin/34934; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: toolchain/34934
Date: Sun, 15 May 2022 08:55:23 +0000

 On Sat, May 07, 2022 at 10:45:02AM +0000, Roland Illig wrote:
  >  Am 14.02.2022 um 22:35 schrieb David Holland:
  >  >   *This* PR is about the sequential form breaking sometimes for targets
  >  >   in other directories. As I pointed out in 2006, by default it works
  >  >   correctly. (If by chance you have broken this recently, please fix
  >  >   it.)
  >  
  >  Thanks for the detailed explanation.
  >  
  >  Do you see any chance of making this "sometimes" or "in some cases" more
  >  specific?
 
 Not without doing a bunch of experiments. I have long forgotten what I
 was doing in 2006 that triggered the initial report :-)
 
 Reading between the lines of what I originally wrote, which does (or
 did then) exhibit both behaviors, and looking at the example, the
 difference is triggered by touching the generator script; that is, in
 the case where it worked, the dep from the output files to the
 generator was satisfied, and where it didn't, it was out of date
 before the recipe was run the first time (but not before it was run
 the second time).
 
 So,
 
  >  When you say "sometimes", does this mean that when running the same
  >  scenario 20 times in a row, 3 of them might fail and the other 17 might
  >  succeed?
 
 I think it meant "depending on the mtime state of the files involved"
 as opposed to "nondeterministically". Very little in non-parallel make
 is nondeterministic :-)
 
 I have figured that the problem was somewhere in the (then, at least)
 rudimentary directory caching layer, something maybe like not flushing
 cached mtimes of files in other directories.
 
 
 However...
 
 ...it no longer behaves according to the description, that is, it
 works in both cases.
 
 I also vaguely recall something in this context involving ".."
 directories, but I just tried it with ../gdir/ insted of gdir/ and it
 still works.
 
 Therefore, I'm inclined to think it's fixed.
 
 
  >  Could it have something to do with .PATH, or is it enough to have
  >  subdir/file?
 
 Very unlikely; I don't ordinarily write makefiles with .PATH (since
 long before 2006) so I wouldn't have hit any related problems.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost