[Top][All Lists]

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

Re: MSVC build test results

From: Eli Zaretskii
Subject: Re: MSVC build test results
Date: Mon, 29 Aug 2005 21:23:58 +0300

> 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

  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

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

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


>   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

reply via email to

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