Re: Automake 1.4l released

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Christopher Faylor wrote:

> On Tue, Aug 14, 2001 at 05:06:00PM -0600, Tom Tromey wrote:
> 
>>>>>>>"Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
>>>>>>>
>>Earnie> Automake is a sister tool to Autoconf and should maintain the
>>Earnie> same effort to maintain portability.
>>
>>That's true.  But we're talking about the capability to run `make
>>distcheck' on a platform where the semantics are not Unix-like in an
>>unanticipated way.
>>
>>I don't have a problem working around bugs in vendor tools.  We do
>>that all the time in automake.  However, I prefer that free software
>>be fixed at the source as well.  That is, we might implement a
>>workaround in automake, but I dislike using that as an excuse to leave
>>other free tools unfixed.


I'm gonna jump back in here before things explode.  I *believe* that a 
workaround to this MSWindows problem was committed to cygwin's utime() 
today.  So that's the 'free software being fixed at the source'.

However, as Earnie pointed out, since this is a problem with MSwindows, 
and not specifically cygwin -- this behavior will show probably show up 
in the other (non-cygwin) windows platforms -- like perhaps native 
cmd.exe.  (Now, I'm not sure if that is even a consideration, since I 
dunno if the autotools are *really* ported to native windows e.g. MSVC, 
or mingw, etc.  That's a topic for you "real" automake people :-).


> 
> I haven't been paying close attention to this topic.
> 
> If I can summarize, I think I'm seeing this:
> 
> 1) New version of automake is released with no Cygwin testing for an
>    important feature.  Or, is this mentioned in the release notes?


Not quite, Chris.  This is a prerelease version of automake.  (yes, 1.5 
is due RSN, but *this* aint it. yet.)  the make distcheck target is a 
new feature that did not exist in automake 1.4 (or even 1.4-pX AFAIK).


> 2) Cygwin people notice and report bug.


okay...


> 3) Cygwin people provide workaround which is rejected.


well, not really.  Since I didn't know what the distcheck was for, I 
suggested changing to '-rw-r--r--' for ALL platforms, not just cygwin.

All I was focused on was that three particular tests failed -- but not 
because of the behavior that those tests were supposed to check (lex3, 
pr9, and pr87).  Those three tests seem to be the only ones that happen 
to exercise the 'make distcheck' target.  Perhaps automake should 
include a specific distcheck test, and NOT call distcheck from lex3, 
pr9, or pr87.

Anyway, I now have learned that distcheck is for testing if the dist 
will work from RO media (like a CDROM), setting perms to -rw-r--r--' 
kinda defeats the purpose.  Especially if we do it for ALL platforms.


> 4) Automake people say "Not a bug.  Fix Cygwin!"


Well, sortof.

 
> AFAICT, the rationale for this stance is that Cygwin is a free software
> project and therefore we should just drop everything and fix "our bug"
> if we want automake to work.  Or, possibly, we're supposed to provide
> a detailed rationale on why it isn't possible to fix this in Windows.


A bit harsh, I think.  OTOH, if "the automake people" are right, it IS 
our bug. (Well, Microsoft's bug.) And we want to act like linux as 
closely as possible, so *if possible* we should try to work around it 
*for cygwin*.

This doesn't fix the problems that *may* show up on other windows-ish 
platforms, but quite frankly that's not OUR (cygwin's) problem. 
However, I raise the issue so that the automake people will be aware of it.


> This seems to ignore the fact that people are using older versions of
> Cygwin.  Is it automake policy to tell people to update to newer OS
> versions when there are problems with automake that can be traced to
> an OS fault?  Or, perhaps a better example would be, Does the automake
> group tell people to upgrade their libc.so when an incompatibility is
> detected?


Well, yeah -- but all this really means is that the 'make distcheck' 
target that is created within an automake'd project's makefiles won't 
work.

E.g:  package foo-1.3.6 is autotool'ed. The maintainer has previously 
run all the autotools and created this 1.3.6 package for release.  I 
download it, and do './configure ; make ; make check ; make install'

It all works.  However, if I try to 'make distcheck' then THAT target 
will fail.  That's if NO changes are made in automake-1.4l or in cygwin.

Wherever this bug gets fixed, it can only make things better -- right 
now they're really pretty good.  Automake isn't "broken" on cygwin. 
It's just that one of the new features doesn't work...yet.


> If not, then clearly automake needs to include a workaround.
> 
> Regardless, in the meantime, we'll investigate whether it is possible to
> work around this *Microsoft Windows* behavior.  If it is possible to fix
> without a lot of fundamental changes in Cygwin, we'll try to get a fix
> into 1.3.3.  That was going to be released in the next couple of weeks.
> It looks like this might delay that.


Urk.  I'm almost sorry I brought it up.  (topic for cygwin-developers 
discussion: skip this problem, release 1.3.3 now, and then release 1.3.4 
soon with whatever fix we come up with?)

--Chuck



--
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/