Re: [MacPerl-Porters] MacPerl 5.8 TODO

At 18:33 Uhr -0400 30.05.2002, Chris Nandor wrote:
>At 18:51 +0200 2002.05.30, Thomas Wegner wrote:
>>	* Tested through E* so far, except CPAN/t
>
>Does that include the ExtUtils:: tests?  Several are failing for me.
>
No, sorry.  I wanted to add these as [open] to the list, but forgot to
do so (yesterday was definitely not my day :/).

Just one thing: Most of the tests, including the ExtUtils:: tests,
still assume to be in the perl/t/ directory, at least that's what
it looks like. This makes fixing @INC issues a real pain in the
rear (ahem...), to be honest. And some tests just don't run,
because they are deeper in the directory tree as expected, i.e.
@INC  = '../lib'; doesn't work. So why have these test been
moved into lib/? Or did I miss something?



At 21:19 Uhr -0400 30.05.2002, Chris Nandor wrote:
[snip]
>Thomas, you want to look at File::Spec, since that's your thing?  :-)

Yes, I'll look into it.

>x2p/s2p.t has two tests failing (after some porting by me).  It is low
>priority.    h2ph and h2xs tests are low priority too.
>
>Maybe I will get to the ExtUtils tests tomorrow.  It's kinda ugly in there,

Yep, more than ugly. 00setup_dummy.t drives me crazy :-).

>but I started on it.  It won't be too tough for most of it.>
>Deep breath.
>
>
>
>So, that takes care of most of it, except for lib.t.
>
>lib.t seems to need some work, or some thought.  It expects things to
>happen in MacPerl's @INC that are not happening, so it is not a matter of
>fixing lib.t.  The behavior is thus:
>
>:perl -I::lib    ::lib:lib.t
>1..12
>ok 1 - use Yup;
>not ok 2 - lib adding at end of @INC
>#     Failed test (::lib:lib.t at line 54)
>#          got: '../lib'
>#     expected: 'stuff/moo'
># @INC == stuff/moo ../lib
>not ok 3 -     auto/ dir in front of that
>#     Failed test (::lib:lib.t at line 56)
>#          got: 'stuff/moo'
>#     expected: 'stuff/moo/MacPPC'
>ok 4 -     no duplicates
>ok 5 - %INC set properly
>ok 6 - do() works
>ok 7 -    require()
>ok 8 -    use()
>ok 9
>ok 10 - @lib::ORIG_INC
>ok 11 - no lib
>ok 12 -    do() effected
># Looks like you failed 2 tests of 12.
>
>It expect to see @INC = ('stuff/moo/MacPPC', 'stuff/moo') but is seeing
>('stuff/moo', '../lib') instead.  I don't know what to do offhand, and am
>inclined to ignore it for now, though thoughts are welcome.  :-)

Correct me if I'm wrong: According to lib.pm's pod, paths are added (not
replaced) to the front of @INC. Thus, tests 2 & 3 expect @INC to be

     ('stuff/moo/MacPPC', 'stuff/moo', '../lib') ,

if we were on Unix, right?


If you agree, and Jarkko agrees, I suggest that lib.pm no longer uses Unix
paths only (if possible).  Although MacPerl tolerates Unix paths to some
degree, we cannot translate Mac OS native paths to Unix paths in all cases
(and e.g. a -d 'stuff/moo/MacPPC', which is done internally, will always
fail). Moreover, we now have File::Spec, which makes creation of platform
specific paths easy.

I've prepared patches to lib.t and lib_pm.PL. I know these changes come
late, but hopefully not too late for Perl 5.8.0? Furthermore, I'm always
a bit nervous regarding VMS et al., but I hope there are no
incompatibilities due to my changes.

Here's what I get with the patches applied:

1..12
ok 1 - use Yup;
ok 2 - lib adding at end of @INC
# @INC == :stuff:moo:MacPPC: :stuff:moo: ../lib
ok 3 -     auto/ dir in front of that
ok 4 -     no duplicates
ok 5 - %INC set properly
ok 6 - do() works
ok 7 -    require()
ok 8 -    use()
ok 9
ok 10 - @lib::ORIG_INC
ok 11 - no lib
ok 12 -    do() effected
# @INC == ../lib


Looks good, hmm ...? :-)  Patches come in a separate message.


Best regards,

--Thomas

P.S. Now looking at File::Spec