Hi
Running perl ./Configure.pl in parrot 0.6.2 for the first time on a new
clean install of Mac OS X 10.4.11 with Xcode 2.5 on a PPC G4 12" powerbook
the following oddities appeared four times:
Use of uninitialized value in concatenation (.) or string at
lib/Parrot/Configure/Step/Methods.pm line 106
Excerpted output is appended at the end of this message.
Line 106 appears in sub _handle_darwin_for_macports
It is relevant to note that I have neither MacPorts nor Fink installed.
It is also interesting that _handle_darwin_for_fink does not cause this
problem.
So far three methods of cleaning this up have surfaces here at YAPC::NA
Parrot Hackathon:
1) Modify lib/Parrot/Configure/Step/Methods.pm
2) Make _handle_darwin_for_macports be like _handle_darwin_for_fink
3) Eliminate _handle_darwin_for_macports and _handle_darwin_for_fink
We are currently in favor of (3) but we are a bit confused as to
how this was designed to work ... can some one clarify the intent for us?
As for (1), the immediate problem is that if MacPorts is not present then
my $ports_include_dir = $conf->data->get( 'ports_include_dir' );
is undefined (line 105)
and hence line 106
if ( -f qq{$ports_include_dir/$file} ) {
throws the error quoted above.
Although a simplistic 'fix' would be to change line 106 to be
if (defined($ports_include_dir) && -f qq{$ports_include_dir/$file}
) {
it is instructive to compare this routine (_handle_darwin_for_macports)
to the code for _handle_darwin_for_fink. The ..._fink code tests defined-ness
and also tries to reduce duplication of {link,ld,cc}flags.
So, (2) perhaps the ..._fink code should be echoed into the ..._macport code.
However, (3), the more we stare at this the more we are wondering
why do _handle_darwin_for_{macports/fink} even exist ... and why are they
being called four times? The purpose of _handle_darwin_for_macports
seems to be to add MacPorts to Parrot Configure's {link,ld,cc}flags
if needed. Yet the way it is called, MacPorts paths will be added
once for each module that is probed (current four: GMP,readline,pcre,OpenGL).
And why just for these four libraries in config/auto? It seems likely
that requiring each library probe in config/auto to call these routines
is error prone when new probes are added.
Why not just add the MacPorts(Fink) paths *once* at the time of testing
for MacPorts(Fink) existance? And if we did that, might we not be able
to eliminate _handle_darwin_for_macports (and _handle_darwin_for_fink)?
Any thoughts on what (and why) should be done?
Regards,
Todd Olson
===== begin excerpt from perl ./Configure.pl ==============
Determining if your platform supports GMP...Use of uninitialized value in
concatenation (.) or string at lib/Parrot/Configure/Step/Methods.pm line
106.
............................no.
Determining if your platform supports readline...Use of uninitialized
value in concatenation (.) or string at
lib/Parrot/Configure/Step/Methods.pm line 106.
dyld: lazy symbol binding failed: Symbol not found: _rl_get_keymap
Referenced from:
/Users/wparrot01/Documents/Development/mill/001/parrot/0.6.2/
01/./test
Expected in: dynamic lookup
dyld: Symbol not found: _rl_get_keymap
Referenced from:
/Users/wparrot01/Documents/Development/mill/001/parrot/0.6.2/
01/./test
Expected in: dynamic lookup
.......................no.
Determining if your platform supports gdbm..............................no.
Determining if your platform supports pcre...Use of uninitialized value in
concatenation (.) or string at lib/Parrot/Configure/Step/Methods.pm line
106.
...........................no.
Determining if your platform supports OpenGL...Use of uninitialized value
in concatenation (.) or string at lib/Parrot/Configure/Step/Methods.pm
line 106.
.........yes, MacOSX_GLUT 5.
===== end excerpt from perl ./Configure.pl ==============
