This is the mail archive of the
mailing list for the Cygwin project.
Re: Automake 1.4l released
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
I thought I saw another workaround which was rejected as being
>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.
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.
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.
Apologies if all of this has been mentioned already.
>Chris> This seems to ignore the fact that people are using older
>Chris> versions of Cygwin. Is it automake policy to tell people to
>Chris> update to newer OS versions when there are problems with
>Chris> automake that can be traced to an OS fault? Or, perhaps a
>Chris> better example would be, Does the automake group tell people to
>Chris> upgrade their libc.so when an incompatibility is detected?
>Do you really think I would answer yes to any of these?
As you are not overly familiar with Cygwin, I'm not very familiar with
automake. I know that autoconf bends over backwards to accomodate older
OSes. I don't know what automake does. I suspected that it would not
be very pragmatic to always say "upgrade" so I was wondering why there
was any discussion about this.
The fact is that cygwin is arguably broken *now*. It will be broken for
a few weeks at least.
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
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.
>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.
I'm sorry that my response came across as angry. I guess I needed round
of adjective deletion on my email. That will teach me to send email
while I have a migraine.
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html