Parrot_Exec_OS_Command interface ?
François PERRAD
When I analyse the failure of t/pmc/sys.t with MinGW32,
I see that this script generates a command depending of the OS
on MSWin32, cmd = ".\parrot temp.imc"
on *nix, cmd = "./parrot temp.imc"
(So with MinGw, the generation of Makefile needs /, and the execution needs \)
The bug can be fixed in ConfigureLand or in Parrot_Exec_OS_Command function.
And the dilemma is :
the interface of Parrot_Exec_OS_Command is OS native command as now,
or is OS independent, like "open dirname/filename"
Francois Perrad.
Michal Jurosz
>
> (So with MinGw, the generation of Makefile needs /, and the execution
> needs \)
>
Yes I can confirm this.
MSYS build:
$ perl -Ilib t/pmc/sys.t
1..1
not ok 1 - spawnw, _config
# Failed test (t/pmc/sys.t at line 26)
# got: '. Command not found
# 1
# '
# expected: 'Hello, World!
# 0
# '
# Looks like you failed 1 tests of 1.
### config_lib.pasm
- set P0["slash"], "/"
+ set P0["slash"], "\\"
$ parrot config_lib.pasm
$ perl -Ilib t/pmc/sys.t
1..1
ok 1 - spawnw, _config
S pozdravem Michal Jurosz
Dan Sugalski
This is a low-level interface and is designed to
be OS-dependent. An OS-independent layer on top
of it wouldn't be bad, but I'm not sure it'd be
too useful as you get really really system
dependent really fast when spawning off
processes. (There's so much more to it than quick
filename munging that I'm not sure it's worth it,
really)
Anyway, any sort of OS-independence should live
on top of the low-level interface, and would be a
reasonable thing to put in a library.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk