Re: [Gnu-arch-users] Make test failure on Cygwin

[John Meinel]

Well, one thing Leroy mention is to use the flag ./configure 
--with-posix-shell=/usr/bin/bash sort of thing. I'm all for that :).

By the way, with your version of the ./configure, make, make install 
stuff does it automatically use the correct version of tar? IE the one 
that compiled with it? Or does it just use whatever version it finds? 
Because I know with Leroy's compile, you specify 
"/usr/share/tla/libexec/tar" so that at runtime it will find the 
modified version of tar/diff/etc.

I'm very curious why the "sed" output is different from the 
"unit-unidata" version. I know I have cygwin designed to use Unix line 
endings internally. At least I believe so. (That's caused problems 
trying to use cmd line cvs versus a Win32 gui cvs.)


Ron Parker wrote:
> On Mon, 05 Jul 2004 17:34:48 -0500, John Meinel <address@hidden> wrote:
>
>
> > There is a problem with make test for
> > hackerlab/tests/fs-tests/unit-file-names.sh
>
>
> I am aware of many make test issues.  I have not updated my archive
> with fixes for all of them because I wanted to fix the issues
> correctly and not simply cause the tests to pass.

Well, a lot of them work if you switch from /bin/sh to /bin/bash (either 
by changing /bin/sh or maybe with the --with-posix-shell option.) The 
problem I ran into is that one Makefile uses $(SHELL), and the other one 
uses $(cfg__posix_shell). Because there is also a ./configure option 
--config-shell, and --with-posix-shell is an undocumented configure 
option. (At least it doesn't show up from ./configure --help)


> > Basically, '/bin/sh' on cygwin is ASH, not BASH. In unit-filenames-sh
> > you do comparisons against "~/...". It turns out that at least on cygwin
> > ash doesn't expand ~/. It does expand "$HOME/" though. Also, /bin/bash
> > does expand "~/".
>
>
> I have run into a number of packages over the years that choke with
> ash as /bin/sh for this and other reasons. So, one of the first things
> I tend to do on a Cygwin system is to move /bin/sh out of the way and
> replace it with BASH.
>
>
> > Is there a specific reason to use "~/", or should I change everything
> > over to "$HOME/"?
>
>
> Personally I don't see a problem with that.

I'm okay with switching to bash as the shell, but I think tla is 
supposed to be designed to support a true POSIX shell. I would assume 
that /bin/ash and /bin/bash and /bin/zsh would all support the basic 
POSIX functions. So expanding ~/ doesn't seem to be a POSIX standard. I 
could be completely wrong, though.
(I remember reading in the past that changing /bin/sh from /bin/bash to 
/bin/ash greatly improved the speed of arch (probably larch at that 
time) because it was spawning _lots_ of shell scripts. So at least at 
one point arch liked /bin/ash just as much as /bin/bash)


> > There is another problem in unit-unidata.sh
> > ,tmp is created from sed, and ,tmp2 is created from ,/unit-unidata
> >
> > Well, at least on my system, sed generates unix-style endings, but
> > unit-unidata generates dos-style endings.
>
>
> It's not just your system.  Long long ago in a galaxy far far away, it
> was decided that the Cygwin text tools should always operate in text
> mode, irrespective of mount mode or anything else and this becomes
> even more obfuscated when dealing with pipes. At least a partial
> description may be found in the thread at
> http://www.cygwin.com/ml/cygwin/2002-08/msg01597.html. My experience
> doesn't seem to completely match this description but I may be having
> a memory fault.

Maybe I just didn't read enough, but what I saw was that a redirect '>' 
works in bin or text depending on mount mode and a pipe works depending 
on the CYGWIN=[no]binmode. I can look into it a little bit more. If that 
fixes it, we might be okay. However, as mentioned, my guess is that sed 
is doing binmode, but unit-unidata is using native mode.

> > If I add dos2unix ,tmp2, then the comparison works. I'm not sure if
> > there is a better way that involves changing unit-unidata.c, or
> > something like that.
>
>
> I am uncertain.  I had refrained from doing this personally because I
> wasn't completely convinced that the cygwin text tool decision might
> not cause actual breakage in tla usage.  I could certainly envision
> the possibility of certain hooks causing cross-platform problems EOL
> issues. I don't think changing the C code would matter, at best this
> would probably make the output work for text-mode mounts, but not for
> binary mounts.

Well, one thing that you could do is run "dos2unix" on both ,tmp and 
,tmp2, then you are at least working with the same data. You could run 
unix2dos, I don't really care. But having the test fail because of line 
endings doesn't seem right. Unless there is something specific about the 
processing chain that requires line endings to be correct, so that a 
failing the test really is a failure.

> > There are also problems with the tests in tla/tests because /bin/sh
> > doesn't support the $(($A + 1)) syntax. So instead of getting "Test 1"
> > "Test 2", you get "Test 1", "Test 1 + 1", etc.
>
>
> I am not familiar enough with strict posix /bin/sh behavior, but this
> may be a common extension from ksh, bash, etc. However, it too was
> "solved" via a /bin/sh transplant.

My guess is there isn't a good POSIX addition operator (I mean $(()) is 
pretty hackish, why does an extra parenthesis matter?). So I don't know 
that there is a good POSIX workaround. Mostly I just wanted to bring up 
the different places where tla violates POSIX since it seems to state 
that it uses only POSIX.

> > Another problem, which I don't know the fix for is "test-import.sh" It
> > fails because of "import: tree has no patch log for version"
> > I'm not sure why. archive-setup, archive-mirror fail for the same reason.
>
>
> It's been a long time since I looked at that, I will have to see what
> I can come up with. I don't remember the solution.

I don't know if this would be the problem, but what if tla is using the 
wrong versions of tar/diff/patch etc?

> > I'm almost to the point where rbp's cygwin port compiles and runs with
> > path compression, and caching.
>
>
> I am aware of "make test" errors, but if you are seeing compilation or
> functional errors I am definitely interested.

Just the auto* errors. One thing I would say is probably we want to 
distribute the "generic" Makefile.in. I was reading some of the help 
files and unless you do "make distsomething" the Makefile.in may not be 
a portable one.	I would like to see the situation where ./configure runs 
configure for all the packages, and then make only does the build. 
Having make also run ./configure for the tar/patch/diffutils stuff 
doesn't seem quite right.

John
=:->