Date: Thu, 19 Aug 1999 11:38:16 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Esa A E Peuha cc: djgpp-workers AT delorie DOT com, "Paul D. Smith" Subject: Re: Make 3.78 is in pretest In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Thu, 19 Aug 1999, Esa A E Peuha wrote: > That's the result I get with the executable you sent me, except for the > following tests (they work for me): > > > features/echoing > > targets/clean These sometimes fail, sometimes don't, even in my case. The exact result depends on several factors: - what does $SHELL point to; - whether PATH uses forward- or back-slashes; - whether there are other files in the work directory. (there might be other factors). > I didn't realize Windows doesn't allow `>' in file names. Windows is not Unix... None of the redirection/pipe characters is allowed, and wildcard characters `*' and `?' are also disallowed. > > 1) features/default_names > > > The problem here is that Makefile and makefile map to the same file > > on DOS/Windows. The solution I suggest is to generate each > > standard makefile just before it is used, as opposed to generating > > them all and then running them all: > > But that would partly defeat the purpose of the test, which is to make > sure that Make searches for the standard makefiles in specific order. I > think this should first test whether Makefile and makefile map to > different files, and then skip creating and testing makefile if they > don't. (Even on DOS it's reasonable to test that Make prefers GNUMakefile > over Makefile.) Can you send a patch? (But before that, please look at the new version of the test suite, which has some Windows-related changes already.) > > 14) targets/clean > > > This uses "...", see features/echoing above. Here's the patch: > > How come these don't work for you? The expansion of "..." depends on whether there are subdirectories when the command runs; if there are no subdirectories, it expands to itself. Therefore, the results depend on how many other tests failed. Also, if you don't have Sh-utils installed, you don't have echo.exe, so the command internal to COMMAND.COM gets invoked instead, and the latter doesn't know about "...". In any case, using "..." alone is dangerous. > Anyway, there's no > reason why the scripts should run echo if the command line is changed as > you suggest. I will try with the original version as well.