Re: Automake 1.4l released

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Tom Tromey wrote:

>>>>>>"Charles" == Charles Wilson <cwilson@ece.gatech.edu> writes:
>>>>>>
> 
> I've read this whole thread
> 
> Charles> That's why I advocate the change: what if other filesystems
> Charles> behave "correctly" (my definition).  In addition, what is the
> Charles> rationale for doing 'chmod -R a-w' in the distdir: rule,
> Charles> anyway?  Isn't 'chmod -R go-w' just as "good" a choice?
> 
> As I recall, the `a-w' change was introduced so that `distcheck' would
> ensure that building from read-only sources would work.  For instance
> this lets us check that there isn't a bug in a Makefile.am causing a
> write to srcdir.
> 
> I think this is a useful check.  It tests for an actual bug which
> people can easily introduce by mistake.  Using `go-w' would
> effectively remove this test.  So by default I would prefer to keep
> this if possible.
> 


Yes, now that I understand why the 'a-w' change was introduced, I agree 
with you.


> Charles> The 'cp -p' command performs the copy in a two step process:
> Charles> first, the file is copied, permissions and all. So, we have a
> Charles> new copy of the file which is ALSO -r--r--r--, but with the
> Charles> wrong timestamp.
> 
> Interesting.
> 
> The reason we want `cp -p' is that preserwhatving timestamps is very
> important to making a correct distribution.  If the timestamps are
> wrong, then, say, configure.in might be newer than configure -- this
> would be very bad.


Yes, I also understand why using the '-p' option is important (that's 
why my original suggestion was not 'drop the -p option').


> Note that people using automake as maintainers on Cygwin is a pretty
> new phenomenon.  I've never heard of anybody trying to run `make dist'
> on Cygwin before.  This failure isn't a plot against Cygwin or
> anything like that; I think it is just new territory.


Yep.  Everything about cygwin+autotools is new territory.  Blame it on 
the goat book -- they had a whole chapter on cygwin+autotools...


> In this particular case I guess I would argue that we're seeing either
> a bug in cp or a Cygwin bug.


Hmm...well, the utime() thing is actually a windows bug.  We can put a 
workaround in the cygwin kernel (as has already been suggested and 
implemented!) so that utime() changes the file's perms (if necessary), 
does the mtime/atime adjustment, and then changes the file's perms back 
(if necessary).

However, it is also possible that cp *complaining* about the failure is 
a bug in cp.  (Or did the fileutils people just *assume* that utime() 
would always work, and if it didn't then that's a bigtime error and not 
a silent error?)


> On Linux and Solaris I can use utime() to change the mtime and the
> atime of a file even though it is `a-w'.  That argues for a Cygwin
> kernel bug.  I haven't reported a Cygwin bug in a long, long time.
> Would you care to do it?  Otherwise I will investigate the procedure.


Already done.  And I think it's been fixed -- but I haven't built a test 
kernel with Corinna's patch yet 'cause I've spent the last hour 
answering email!  :-)

--Chuck