[perl #40455] [PATCH] Bring dotnet back into unified languages testing

Bernhard Schmalhofer

unread,

Oct 4, 2006, 3:26:37 PM10/4/06

to bugs-bi...@rt.perl.org

# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #40455]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40455 >

Hi,

since a while 'languages/dotnet' showed up as all red in unified
languages testing, which is
invoked with "make languages-test". The culprits were the usual bunch:
@INC and pathes to executables.

I have expanded the library search path in the test scripts. Also
DotnetTesting.pm now asks
Parrot::Test for the path to the parrot executable.

Could somebody check for breakage on Windows?
Any other suggestions?

CU, Bernhard

dotnet_in_languages_testing.patch

Francois Perrad

unread,

Oct 9, 2006, 4:53:29 AM10/9/06

to perl6-i...@perl.org, Bernhard.S...@gmx.de

Your patch works on Win32/MinGW.
See
http://smoke.parrotcode.org/smoke/parrot-smoke-0.4.6-devel-r14861-unknown--i386-MSWin32-gcc-default--1160383280-1044--2034-1692-342-40-19-0--6c616e677561676573--c2f964d92d75f247ee11b48087ad2be4.html

François.

Francois Perrad

unread,

Oct 9, 2006, 5:32:25 AM10/9/06

to perl6-i...@perl.org, Bernhard.S...@gmx.de

At 12:26 04/10/2006 -0700, you wrote:

1) remove the need of the file languages/dotnet/config/N2PConfig.pm
2) generate languages/dotnet/Makefile with config/gen/languages.pm, not
with languages/dotnet/Configure.pl

François.

>CU, Bernhard

Jonathan Worthington

unread,

Oct 12, 2006, 4:41:07 AM10/12/06

to François PERRAD, perl6-i...@perl.org, Bernhard.S...@gmx.de

Hi,

Thanks to @all working on getting dotnet translator back into unified
language testing. I'll be hacking on the translator more when I return
from consulting work in Spain, so this is certainly good to have. :-)

François PERRAD wrote:
>> Any other suggestions?
>
> 1) remove the need of the file languages/dotnet/config/N2PConfig.pm

Go ahead. This was a hack while I was developing the translator
initially and it was outside of the Parrot source tree.

> 2) generate languages/dotnet/Makefile with config/gen/languages.pm,
> not with languages/dotnet/Configure.pl

This is not so easy, since languages/dotnet/Configure.pl takes various
parameters:

--srm to configure which stack to register mapping algorithm to build with
--monolibs to give the path to the Mono version of the .Net class
library, for the make class-library target (which tries to translate the
class library to Parrot bytecode)

I need (OK, really, really want) to be able to switch SRMs without
having to re-configure all of Parrot 'cus it's very useful to do this in
development, when hunting the source of code generation bugs.

As for the class library path stuff: yes, you do only need to
locate/configure this once, but again, if someone doesn't know that and
then want to build the .Net translator, I don't think they should have
to to back and re-configure Parrot and pass a --monolibs=... to the main
Configure script.

Thanks,

Jonathan

Will Coleda

unread,

Oct 12, 2006, 7:34:45 AM10/12/06

to François PERRAD, perl6-i...@perl.org, Bernhard.S...@gmx.de

While this isn't currently how most languages operate, I like this
way better. =-)

As a language person, I'd rather actually have the makefile generated
by the language, not parrot. Makes it easier when you're working on
the language. Also allows you to remove any language specific config
probes from parrot-wide configure.

Getting the languages *more* self-contained is a good thing. (I don't
have a good answer for a dozen very similar Configure.pl scripts at
the moment, though.)

Regards.

> François.
>
>> CU, Bernhard
>
>
>

--
Will "Coke" Coleda
wi...@coleda.com