[perl #41597] [PATCH] replacing explicit access to $^O in Configure

2 views
Skip to first unread message

Aldo Calpini

unread,
Feb 23, 2007, 10:28:38 AM2/23/07
to bugs-bi...@rt.perl.org
# New Ticket Created by Aldo Calpini
# Please include the string: [perl #41597]
# in the subject line of all future correspondence about this issue.
# <URL: 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 configure process instead of $^O (and $Config{osname}).

this patch does not affect the current configuration process. in the
long term, an --osname parameter (along with --arch and others,
probably) will be added to Configure.pl, to provide support for
cross-compilation.

as of now, the value of $conf->data->get('osname') ALWAYS returns $^O.

cheers,
Aldo

osname.patch

Bernhard Schmalhofer via RT

unread,
Nov 10, 2007, 6:07:29 AM11/10/07
to perl6-i...@perl.org
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 parameter (along with --arch and others,
> probably) will be added to Configure.pl, to provide support for
> cross-compilation.
>
> as of now, the value of $conf->data->get('osname') ALWAYS returns $^O.

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 ?

Regards,
Bernhard

--
/* Bernhard.S...@gmx.de */

Jerry Gay

unread,
Nov 28, 2007, 9:58:08 AM11/28/07
to parrotbug...@parrotcode.org
On Nov 10, 2007 3:07 AM, Bernhard Schmalhofer via RT
yes, please!
~jerry

James Keenan via RT

unread,
Nov 28, 2007, 1:46:30 PM11/28/07
to perl6-i...@perl.org
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 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 applied as well. Since it was originally submitted early
in the year, we may have to double-check the locations to which it is
being applied to get it to work correctly. Here's where $^O is
currently being invoked under config/:

[parrot] 509 $ fnsa config/ '*.pm' | xargs grep -n '$^O'
config/inter/progs.pm:99: $libs = join ' ', grep { $^O =~ /VMS|MSWin/
|| !/^-l(c|gdbm(_compat)?|dbm|ndbm|db)$/ }
config/init/hints.pm:41: my $hints = "init::hints::" . lc($^O);
config/auto/headers.pm:113: if ( $^O eq "msys" ) {
config/auto/gdbm.pm:71: if ( $^O =~ /mswin32/i ) {
config/auto/gmp.pm:54: if ( $^O =~ /mswin32/i ) {
config/auto/readline.pm:43: if ( $^O =~ /mswin32/i ) {
config/auto/gcc.pm:402: if $^O eq 'hpux';
config/auto/alignptrs.pm:48: elsif ( $^O eq 'hpux' &&
$Config{ccflags} !~ /DD64/ ) {
config/gen/config_h.pm:83: print {$HH} "\n#define BUILD_OS_NAME
\"$^O\"\n";
config/gen/platform.pm:39: my $platform = lc $^O;

James Keenan via RT

unread,
Nov 28, 2007, 2:46:35 PM11/28/07
to perl6-i...@perl.org
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 $osname ) {
57: ( $osname, $cpuarch ) = ( $cpuarch, q{} );
66: $osname = 'darwin';
75: # cpuarch and osname are reversed in archname on windows
77: $cpuarch = ( $osname =~ /x64/ ) ? 'amd64' : 'i386';
78: $osname = 'MSWin32';
80: elsif ( $osname =~ /cygwin/i || $cpuarch =~ /cygwin/i ) {
82: $osname = 'cygwin';
93: warn "osname: $osname\ncpuarch: $cpuarch\n" if $verbose;
98: osname => $osname
101: my $jitarchname = "$cpuarch-$osname";
125: if ( $cpuarch eq 'i386' && $osname eq 'darwin' ) {
147: my ( $jitcpuarch, $jitosname ) = split( /-/, $jitarchname );
153: jitosname => uc($jitosname),
165: unless ( ( $osname eq 'openbsd' )
166: || ( $osname eq 'freebsd' )
167: || ( $osname eq 'netbsd' )
168: || ( $osname eq 'linux' )
169: || ( $osname eq 'darwin' )
170: || ( $osname eq 'MSWin32' ) )
195: if ( -e "config/auto/jit/test_exec_$osname.in" ) {
197: cc_gen("config/auto/jit/test_exec_$osname.in");
231: jitosname => $osname,

Bernhard Schmalhofer

unread,
Nov 28, 2007, 4:51:21 PM11/28/07
to parrotbug...@parrotcode.org, James E Keenan, perl6-i...@perl.org
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 applied as well. Since it was originally submitted early
> in the year, we may have to double-check the locations to which it is
> being applied to get it to work correctly. Here's where $^O is
> currently being invoked under config/:
>
> [parrot] 509 $ fnsa config/ '*.pm' | xargs grep -n '$^O'
> config/inter/progs.pm:99: $libs = join ' ', grep { $^O =~ /VMS|MSWin/
> || !/^-l(c|gdbm(_compat)?|dbm|ndbm|db)$/ }
> config/init/hints.pm:41: my $hints = "init::hints::" . lc($^O);
> config/auto/headers.pm:113: if ( $^O eq "msys" ) {
> config/auto/gdbm.pm:71: if ( $^O =~ /mswin32/i ) {
> config/auto/gmp.pm:54: if ( $^O =~ /mswin32/i ) {
> config/auto/readline.pm:43: if ( $^O =~ /mswin32/i ) {
> config/auto/gcc.pm:402: if $^O eq 'hpux';
> config/auto/alignptrs.pm:48: elsif ( $^O eq 'hpux' &&
> $Config{ccflags} !~ /DD64/ ) {
> config/gen/config_h.pm:83: print {$HH} "\n#define BUILD_OS_NAME
> \"$^O\"\n";
> config/gen/platform.pm:39: my $platform = lc $^O;
>
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.

Regards,
Bernhard

James E Keenan

unread,
Nov 28, 2007, 6:47:53 PM11/28/07
to perl6-i...@perl.org, Bernhard Schmalhofer, parrotbug...@parrotcode.org
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, init::defaults, we should define a space within the
Parrot::Configure object in which we store our readings from the
%Config, $^O and other readings we take from the instance of Perl being
used to run Configure.pl ($^X, in other words). We'll take these
readings in that step and then assign them to "real" elements in the
Parrot::Configure object as needed. Later configuration steps which
need the "original" values will consult this special section.

I will work on this tonight and over the next few days.

James Keenan via RT

unread,
Nov 28, 2007, 8:12:33 PM11/28/07
to perl6-i...@perl.org

To accommodate this work, I have created the initp5 branch in the Parrot
SVN repository.

James Keenan via RT

unread,
Nov 28, 2007, 10:23:14 PM11/28/07
to perl6-i...@perl.org
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 $Config{osname}'
darwin
[parrot] 507 $ perl -le 'print $^O'
darwin

In other words, does $Config{osname} simply record the content of $^O
for a given platform?

Thank you very much.

kid51

James Keenan via RT

unread,
Dec 1, 2007, 9:40:57 AM12/1/07
to perl6-i...@perl.org
On Wed Nov 28 19:23:13 2007, jk...@verizon.net 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'
> darwin
>
> In other words, does $Config{osname} simply record the content of $^O
> for a given platform?
>

Yes.

James Keenan via RT

unread,
Dec 1, 2007, 9:47:23 AM12/1/07
to perl6-i...@perl.org
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/144446/diff.noConfig.patch.txt

I did not implement a command-line option for 'osname' because (a) I
don't think we need it quite yet and (b) when we do implement it, it
will probably be in a configuration step of its own.

In other respects, I tried to follow the intent of Aldo's original
submission. Once committed, we will take a reading on $^O in the second
configuration step, init::defaults, place it in a part of the
Parrot::Configure object where we store other readings from the Perl
environment, and then look up that value at points in later
configuration steps where we have taken a direct reading on $^O.

kid51

Chromatic

unread,
Dec 1, 2007, 1:51:28 PM12/1/07
to perl6-i...@perl.org, parrotbug...@parrotcode.org

We'll probably have to perform a similar replacement in the remaining tests,
at least to make cross-compilation test correctly. This is a good step
toward that.

-- c

James Keenan via RT

unread,
Dec 1, 2007, 2:32:52 PM12/1/07
to perl6-i...@perl.org
On Sat Dec 01 10:52:27 2007, chro...@wgz.org 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 configuration step classes were correct in using
the Perl 5 %Config, $^O, etc. as places to look up values for assignment
to slots in the Parrot::Configure object. So what I've done so far is
to simply replace a direct lookup with an indirect one.

That assumption will probably not hold once we get to cross-compilation,
but at least now the assumption is explicit.

James Keenan via RT

unread,
Dec 3, 2007, 8:01:58 PM12/3/07
to perl6-i...@perl.org
Patches applied to trunk in r23427 Dec 03 2007.

James Keenan via RT

unread,
Jan 11, 2008, 4:36:43 PM1/11/08
to perl6-i...@perl.org
No complaints over the past 7 weeks, so I'm resolving the ticket.

kid51

Reply all
Reply to author
Forward
0 new messages