[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automake 1.4l released

From: Christopher Faylor
Subject: Re: Automake 1.4l released
Date: Tue, 14 Aug 2001 19:59:23 -0400
User-agent: Mutt/1.3.11i

On Tue, Aug 14, 2001 at 05:06:00PM -0600, Tom Tromey wrote:
>>>>>> "Earnie" == Earnie Boyd <address@hidden> 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 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 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]