Re: MSVC build test results

[Eli Zaretskii]

> Date: Mon, 29 Aug 2005 09:35:04 -0400
> From: "Paul D. Smith" <address@hidden>
> Cc: GNU Make W32 <address@hidden>
> 
> %% "J. Grant" <address@hidden> writes:
> 
>   jg> features/export ................... FAILED (9/10 passed)
> 
> I really don't understand why this failed, especially when the other
> tests succeeded.
> 
> Maybe someone can look into this one?

I'll try if no one beats me to it.

>   jg> features/parallelism .............. FAILED (4/5 passed)
> 
> What's the status of parallelism in GNU make?

You mean, in the Windows port?  It works okay, as far as I could see
and test.  I ran all the parallelism tests manually with Make compiled
by the MinGW port of GCC, and all tests produced exactly the expected
results.

  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.

I would ask the OP where did he/she get this particular port of
`sleep'.

> 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".
> 
> Because of this difference, these tests are all failing.
> 
> We need to determine some way of having the Perl test suite compute the
> same value that is computed by the getcwd_fs() function that make uses.
> The Perl function that does the work is run_make_tests.pl:get_this_pwd(),
> FYI.

How about if you chdir into the directory and see what getwd returns?

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

What is the purpose of this test?  If it tests shell escaping, then
it doesn't make sense to test that on Windows, and the test should be
disabled unless $SHELL points to something like sh.exe (modulo leading
directories).

>   jg> options/dash-l .................... FAILED (0/1 passed)
> 
> Hm.  This one is because -l isn't supported on Windows, I'm sure.

Yes.

>   jg> variables/SHELL ................... FAILED (1/5 passed)
> 
> Hm.  I added a patch which fixed at least some of the problems, but it
> still is failing for you.
> 
> Somehow, even though I set the make variable SHELL to a value like this:
> 
>     SHELL := /./$(SHELL)
> 
> when I echo $(SHELL) (the make variable value, note!) I get just the old
> version of $(SHELL), with no /./ on the front.  Maybe some code
> somewhere is sanitizing this?

There's a lot of tricky handling of SHELL going on on non-Posix
platforms.