Mail Archives: djgpp-workers/1999/08/19/04:44:12
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.
- Raw text -