[Top][All Lists]

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

Re: Automake 1.4l released

From: Charles Wilson
Subject: Re: Automake 1.4l released
Date: Tue, 14 Aug 2001 22:00:39 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713

Tom Tromey wrote:

"Charles" == Charles Wilson <address@hidden> 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 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.


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, 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! :-)


reply via email to

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