Re: MSVC build test results

[J. Grant]

Hi Paul,

Thanks for going through the logs.

Not sure about some of the issues you have raised, sounds like Eli has some
good ideas about them.

>   jg> features/parallelism .............. FAILED (4/5 passed)
>
> What's the status of parallelism in GNU make?  This seems to be an issue
> with either parallelism or the "sleep" command in the shell/whatever;
> just taking the first line, make runs two commands in parallel: the
> first sleeps for 1 second then prints something, the second one prints
> something then sleeps for 2 seconds.  Somehow in this result, the text
> printed after the 1 second sleep appears BEFORE the text printed
> immediately.

MSYS comes with GNU sleep (sh-utils) 2.0

>   jg> features/patspecific_vars ......... Error running 
> C:/msys/1.0/local/bin/make (expected 0; got 512): C:/msys/1.0/local/bin/make -f 
> work/features/patspecific_vars.mk
>   jg> FAILED (6/7 passed)
>
> OK, I think I have a fix for this one.

Great! Let me know when the code is commited, and I will run through the
tests again.

>   jg> features/recursion ................ FAILED (1/2 passed)
>   jg> options/dash-C .................... FAILED (0/2 passed)
>   jg> options/dash-I .................... FAILED (0/2 passed)
>   jg> targets/DEFAULT ................... FAILED (0/1 passed)
>   jg> variables/CURDIR .................. FAILED (0/1 passed)
>   jg> variables/MAKE .................... FAILED (0/1 passed)
>
> These are all caused by a difference of opinion on the current working
> directory by pwd vs. GNU make.  Make, with WINDOWS32 set, uses
> getcwd_fs() to determine the working directory and returns values like
> "/home/now3d/make/tests".
>
> There is no portable "getwd" function in Perl, so our test suite uses
> `pwd` to figure the working directory.  That appears to return values
> like "C:/msys/1.0/home/now3d/make/tests".

Hmm, when I type pwd in MSYS/rxvt I see /home/now3d/make/tests displayed.

[...]
>   jg> functions/abspath ................. Error running 
> C:/msys/1.0/local/bin/make (expected 0; got 512): C:/msys/1.0/local/bin/make -f 
> work/functions/abspath.mk
>   jg> FAILED (0/1 passed)
>
> I don't know why this failed but I've enhanced the test suite so that it
> prints more information.

Great.

>   jg> functions/eval .................... FAILED (8/9 passed)
>
> Hrm.  This fails because in a POSIX shell this command:
>
>     echo hel\lo
>
> print "hello" while on Windows, apparently, it prints "hel\lo"
> (backslashes not handled the same way).
>
> Not sure what to do about this.
>
>   jg> misc/general3 ..................... FAILED (9/10 passed)
>
> This has something to do with the way backslash/newline is handled.
> Is this environment using a unixy shell or not?
>
>   jg> options/dash-B .................... FAILED (5/7 passed)
>   jg> variables/MAKE_RESTARTS ........... FAILED (0/3 passed)
>
> Don't get these; why are the variables being printed out of order?
> Maybe some kind of IO flush problem?  This is not conformant to the ISO
> spec though.

Maybe. I have seen lines being cut off half way and intermixed on win32
builds which both try to write to stdout from threads/dlls.

>   jg> options/symlinks .................. Error running 
> C:/msys/1.0/local/bin/make (expected 0; got 512): C:/msys/1.0/local/bin/make -f 
> work/options/symlinks.mk.2 -L
>   jg> FAILED (4/10 passed)
>
> Hm.  There's code in the test suite to check whether the system supports
> symlinks or not, and it skips all these tests if it doesn't.
>
> But, apparently, that is not working!  The perl docs say that if you try
> to use the symlink() function on a system that doesn't support it, it
> will die.  So, you invoke the function in an eval{} to see if it works
> without killing the script, which I do, but apparently it is still true
> on your system?
>
> Can you investigate this?

Perhaps we could disable symlink testing on MinGW/MSVC MSYS or win32
test environments? (I think we can indentify that)

Kind regards
JG