Ticket #1194 (closed bug: fixed)
7 config steps improperly rely on Perl 5 %Config 'OSNAME' element
Reported by: | jkeenan | Owned by: | jkeenan |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | configure | Version: | 1.7.0 |
Severity: | medium | Keywords: | |
Cc: | mikehh | Language: | |
Patch status: | Platform: |
Description
In the course of working on TT #1189, I have stumbled upon certain problems with the Parrot configuration system which go beyond the question of the dependence of the t/steps/*.t tests on init::defaults.
In this ticket I describe one such problem: Several configuration steps depend on the value for OSNAME found in the Perl 5 %Config even after Parrot's Configure.pl has made a later (and, presumably, better) determination of what osname should be.
The Parrot configuration value for osname is determined in auto::arch. One would therefore expect that when subsequent configuration steps needed to know the name of the operating system for some purpose, it would use osname. The following configuration steps, however, continue to rely on the value found in the Perl 5 %Config:
config/auto/gettext.pm config/auto/opengl.pm config/auto/gmp.pm config/auto/gdbm.pm config/auto/crypto.pm config/auto/readline.pm config/auto/pcre.pm
The above files have code like this:
my $osname = $conf->data->get_p5('OSNAME');
... instead of code like this:
my $osname = $conf->data->get('osname');
Unless someone beats me to it, I plan to start a branch to convert the seven files above to using Parrot's osname.
(Note: There are other issues here which I'll defer to future tickets: Is auto::arch's method for determining osname correct? Where should auto::arch fall in the sequence of configuration steps? What do we do about configuration steps (e.g., auto::headers) which request the Perl 5 OSNAME but which come before auto::arch in the configuration step sequence?)
Thank you very much.
kid51