[Top][All Lists]

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

Re: Automake 1.4l released

From: Charles Wilson
Subject: Re: Automake 1.4l released
Date: Tue, 14 Aug 2001 21:24:08 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713

Christopher Faylor wrote:

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'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.


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 when an incompatibility is

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?)


reply via email to

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