From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Faylor To: cygwin@Cygwin.Com Cc: automake@gnu.org, Bernard Dautrevaux , tim.van.holder@pandora.be Subject: Re: Automake 1.4l released Date: Tue, 14 Aug 2001 18:16:00 -0000 Message-id: <20010814211617.C8849@redhat.com> References: <3B7974C6.83934084@yahoo.com> <3B797B22.C06C71D9@yahoo.com> <87bslip7hj.fsf@creche.redhat.com> <20010814195923.A28367@redhat.com> <87wv46uoac.fsf@creche.redhat.com> X-SW-Source: 2001-08/msg00651.html 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. I thought I saw another workaround which was rejected as being too slow. >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 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. >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. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/