id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	lang	patch	platform
1194	7 config steps improperly rely on Perl 5 %Config 'OSNAME' element	jkeenan	jkeenan	"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"	bug	closed	normal		configure	1.7.0	medium	fixed		mikehh