This is the mail archive of the
mailing list for the Cygwin project.
Re: Automake 1.4l released
- To: Cygwin at Cygwin dot Com
- Subject: Re: Automake 1.4l released
- From: Christopher Faylor <cgf at redhat dot com>
- Date: Tue, 14 Aug 2001 19:59:23 -0400
- Cc: Bernard Dautrevaux <Dautrevaux at microprocess dot com>, "'Tim Van Holder'" <tim dot van dot holder at pandora dot be>, automake at gnu dot org
- References: <3B7974C6.email@example.com> <3B797B22.C06C71D9@yahoo.com> <firstname.lastname@example.org>
- Reply-To: cygwin at Cygwin dot Com
On Tue, Aug 14, 2001 at 05:06:00PM -0600, Tom Tromey wrote:
>>>>>> "Earnie" == Earnie Boyd <email@example.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
>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 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?
2) Cygwin people notice and report bug.
3) Cygwin people provide workaround which is rejected.
4) Automake people say "Not a bug. Fix Cygwin!"
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.
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
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html