Re: Automake 1.4l released

[Charles Wilson]

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