bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Simpler example of pathological behavior of directory caching


From: Eli Zaretskii
Subject: Re: Simpler example of pathological behavior of directory caching
Date: Thu, 06 Oct 2016 22:03:51 +0300

> From: Kyle Rose <address@hidden>
> Date: Thu, 6 Oct 2016 11:47:02 -0700
> Cc: address@hidden
> 
> $ make --version
> GNU Make 4.2.1
> Built for i686-pc-linux-gnu
> Copyright (C) 1988-2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> $ make
> touch target1
> touch target2
> touch target3
> touch target4
> touch target5
> touch target6
> touch target7
> touch target8
> touch target9
> touch target10
> glob:
> $ make
> glob: target10 target3 target8 target7 target6 target5 target1 target2 
> target9 target4
> 
> 4.2.1 definitely broken, at least on my system. 
> 
> >> Why not refresh the cache when the directory's mtime has changed?
> 
>  Because not all systems have the same rules for directory mtime as
>  POSIX does, so that's not a reliable/portable indicator.
> 
> What does POSIX have to say about returning the wrong value for $(wildcard 
> ...)?
> 
>  There's no question the caching needs to be improved.
> 
> Consistency may be desirable in general, but correctness in my environments 
> (mainly Linux and OS X) is
> more desirable for me. Given the various ifdefs around Windows, for instance, 
> there's already no guarantee
> of consistency of behavior across OSes, so I'm not really convinced by that 
> argument.

It works as you'd expect for me even on MS-Windows, as it did for Paul
on GNU/Linux, so I'm curious what kind of filesystem do you have
there.  (I think this issue has much more to do with the type of
filesystem than with the OS.)

> In any event, the existing behavior is a flat-out defect and should be 
> corrected.

Can you step through the code and explain why it happens, though?  A
problem cannot be fixed if it is not understood well enough.

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]