[perl #41597] [PATCH] replacing explicit access to $^O in Configure
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
Bernhard Schmalhofer via RT
> 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
~jerry
James Keenan via RT
>
> 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
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
> (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;
>
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
>>
> 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
To accommodate this work, I have created the initp5 branch in the Parrot
SVN repository.
James Keenan via RT
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
> 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
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
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
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
James Keenan via RT
kid51