No complaints over the past 7 weeks, so I'm resolving the ticket.
kid51
Patches applied to trunk in r23427 Dec 03 2007.
On Sat Dec 01 10:52:27 2007, [EMAIL PROTECTED] wrote:
O.
>
> We'll probably have to perform a similar replacement in the remaining
> tests,
> at least to make cross-compilation test correctly.
Yes. For the purpose of this test, I assumed that the original authors
and maintainers of the configu
On Saturday 01 December 2007 06:47:23 James Keenan via RT wrote:
> I wove what I was doing on this RT into what I was doing in
> http://rt.perl.org/rt3/Ticket/Display.html?id=47902 and have submitted
> the results in a patch attached to that ticket:
> http://rt.perl.org/rt3/Ticket/Attachment/32432
I wove what I was doing on this RT into what I was doing in
http://rt.perl.org/rt3/Ticket/Display.html?id=47902 and have submitted
the results in a patch attached to that ticket:
http://rt.perl.org/rt3/Ticket/Attachment/324326/16/diff.noConfig.patch.txt
I did not implement a command-line opti
On Wed Nov 28 19:23:13 2007, [EMAIL PROTECTED] wrote:
> For a given instance of perl on a given OS, can I assume that the two
> commands below will *always* produce the same output?
>
> [parrot] 506 $ perl -MConfig -le 'print $Config{osname}'
> darwin
> [parrot] 507 $ perl -le 'print $^O'
> darwi
The intent of Aldo's patch is even closer than I first thought to what I
proposed last night ... as is evident from this question:
For a given instance of perl on a given OS, can I assume that the two
commands below will *always* produce the same output?
[parrot] 506 $ perl -MConfig -le 'print $C
On Wed Nov 28 15:48:32 2007, [EMAIL PROTECTED] wrote:
> Bernhard Schmalhofer wrote:
>
> >>
> > James,
> >
> > could you look into this patch and apply it if appropriate?
> > Obviously you are the person that knows best, whether
> > it can be applied right away or needs some fiddling or merging
Bernhard Schmalhofer wrote:
James,
could you look into this patch and apply it if appropriate?
Obviously you are the person that knows best, whether
it can be applied right away or needs some fiddling or merging.
Yes. In line with my second post in RT 47902, I'm thinking that in step
#2
James Keenan via RT schrieb:
(I'm surprised this patch slipped beneath my radar, as it refers to
files I've been staring at for months.)
This is very consistent with what I've recommended for %Config in
http://rt.perl.org/rt3//Public/Bug/Display.html?id=47902, so I recommend
this patch be applie
But one more thought ...
How will creating an 'osname' key from $^O affect/be affected by all the
fiddling done with OS and platform names in config/auto/jit.pm?
[parrot] 512 $ grep -n osname config/auto/jit.pm
49:my ( $cpuarch, $osname ) = split( /-/, $archname );
56:if ( !defined $osna
On Sat Nov 10 03:07:27 2007, bernhard wrote:
>
> This patch hasn't been applied yet.
> It make sense to me as it is a prerequisite for cross-compilation.
>
> Should I go ahead and try to apply the patch ?
>
(I'm surprised this patch slipped beneath my radar, as it refers to
files I've been sta
On Nov 10, 2007 3:07 AM, Bernhard Schmalhofer via RT
<[EMAIL PROTECTED]> wrote:
> On Fr. 23. Feb. 2007, 07:28:38, acalpini wrote:
> > this patch adds an 'osname' key to Parrot's own $conf->data, which is
> > used in the configure process instead of $^O (and $Config{osname}).
> >
> > this patch does
On Fr. 23. Feb. 2007, 07:28:38, acalpini wrote:
> this patch adds an 'osname' key to Parrot's own $conf->data, which is
> used in the configure process instead of $^O (and $Config{osname}).
>
> this patch does not affect the current configuration process. in the
> long term, an --osname paramete
# New Ticket Created by Aldo Calpini
# Please include the string: [perl #41597]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41597 >
this patch adds an 'osname' key to Parrot's own $conf->data, which is
used in the confi
15 matches
Mail list logo
