automake
[Top][All Lists]
Advanced

[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 21:50:23 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713

Christopher Faylor wrote:

On Tue, Aug 14, 2001 at 07:04:11PM -0600, Tom Tromey wrote:

Chris> 3) Cygwin people provide workaround which is rejected.

The original suggestion was "disable the feature".  I'd prefer not to
do that.


Well, I guess so. I didn't really understand the feature; I did not realize (although I now understand) that changing the -r--r--r-- to -rw-r--r-- is equivalent to disabling the feature.



I thought I saw another workaround which was rejected as being
too slow.


Well, there were two. One was a suggestion for US (cygwin), which was to chmod +w ; do the timestamp thing ; chmod -w. I squashed that one because I thought it would slow down EVERY file access and dir listing on cygwin. As it happens, Corinna's suggested patch does exactly this -- but only inside the utime() function, AFAICT. THAT slows down only utime(), not everything else

The other suggestion was to basically do ^^^^^^ within the automake script/generated Makefile.in's. I think that got squashed (by not-me) because of speed concerns, too. I think.

Chris> AFAICT, the rationale for this stance is that Cygwin is a free
Chris> software project and therefore we should just drop everything
Chris> and fix "our bug" if we want automake to work.

Please don't put words in my mouth.  Of course I don't think you
should drop anything for this problem.  If it is a bug, which I don't
even know for certain, then my preference would be that you prioritize
it along with all the other things that you prioritize.

Chris> Or, possibly, we're supposed to provide a detailed rationale on
Chris> why it isn't possible to fix this in Windows.

Or maybe you could choose not to care that `cp -p' doesn't work.


Well, it does work. It preserves file attributes if possible -- even under cygwin. It's just that it (currently) is not possible to preserve those attributes on cygwin in all of the circumstances in which it IS possible to do so on linux. (got that?)

Oh yeah -- and it cygwin's cp complains when it isn't possible to preserve attributes. linux's cp doesn't. Or at least that's the way it appears.


It actually doesn't work very well on non-NTFS filesystems.  That's
known.  We use what Microsoft provides us and we don't have much
to work with on anything besides NTFS.

We could add code to cygwin which stored permissions in a separate
file on FAT "filesystems" but we've always been reluctant to add
that amount of overhead.  U/WIN does this, though.


All this, just so a maintainer-mode target works on cygwin+FAT? I hate to be a party pooper, but so what? Tom's right: cygwin hasn't been a popular *maintainer* platform yet -- and for those that WANT to use cygwin as a platform for autotool-based project maintainance, is it unreasonable to assume that NTFS+ntsec will be used?

Perhaps the automake docs could mention that as a "requirement" on cygwin? *Assuming* we can get the behavior fixed. on cygwin/NTFS. which I think Corinna just did.


Basically, getting 'cp -p' to work on non-NTFS is a lot of work
and no one has shown any interest in doing it.  This hasn't been
a big issue until now, AFAICR.


As I said, I still don't think cygwin+automake+FAT+maintainer-mode is a big deal. Possibly not even nativeWin+automake+maintainer-mode (NTFS or FAT) -- but that's a decision for the automake folks. cygwin+automake+NTFS+maintainer-mode MAY be important; personally, I'd like to restrict the discussion to just that narrow interest.


[snip rant about forced upgrades]


The fact is that cygwin is arguably broken *now*.  It will be broken for
a few weeks at least.


Not really.  See my other message.


I'm not sure why there would be any hesitation to adding some sort of
workaround in automake.  Isn't that what you would do with any broken
vendor OS?  IMO, it is the only sane thing you can do if you don't want
to spend an annoying amount of time saying "Upgrade your
Cygwin/Solaris/Linux/Whatever."


The other alternative is to document Cygwin's problem and hope that
enough people will read the documentation so that the bug report flow
won't be too high.


we're talking about a pretty esoteric topic (using automake to maintain -- not merely build -- a project on cygwin). PLUS, even if you DO maintain a project using cygwin as your platform, only the distcheck target fails.

I think the bug-report rate will probably be pretty low -- EVEN if no changes are made to EITHER cygwin OR automake. However, perhaps a note in the automake documentation about maintainer mode, cygwin, and requiring NTFS. (or did I already say that?)

But first, I'd like to fix the problems with cygwin on NTFS! (But I *think* Corinna's utime() change does that...I'll test it in a while)


If I made you angry, then I'm sorry.  I have to say I'm surprised
though.  I thought I made my desire clear in my post.  For instance, I
said I would consider a workaround in automake as well as preferring
that a real fix be made upstream, either in Cygwin or `cp' as
appropriate.  Maybe you prefer otherwise.


I thought I made this same sentiment pretty clear, too.  I think that
automake should include a work around, if possible, and I think that
Cygwin should be fixed, if possible.


Ah...fix both! Not one or the other!

We are always interested in fixing UNIX compatibility bugs when they
don't involve excessive amount of kludging, and sometimes even then.
You can consider it a given that if we hear about a problem it is put on
our list of things to fix.  The only time we fix the tools rather than
the DLL is when there seems to be no other way to solve the problem.


Yeah...what he said.

--Chuck





reply via email to

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