[3414] in testers

home help back first fref pref prev next nref lref last post

perl4/5 errors in *.ph files

daemon@ATHENA.MIT.EDU (Jacob Morzinski)
Sun Mar 29 03:47:50 1998

To: perldev@MIT.EDU
Cc: testers@MIT.EDU
Date: Sun, 29 Mar 1998 03:47:42 EST
From: "Jacob Morzinski" <jmorzins@MIT.EDU>

Of course, *.ph files in general seem to be extremely fragile.
Do we care about broken-ness?

I did a quick check of the ph directories for both the "perl"
and the "perl5" lockers, for the four major platforms
(sgi_53|sun4x_55|i386_linux2|i386_nbsd) .

The check involved running
  perl -e 'require "foo.ph"'
for each file available, and checking if any warnings or errors
were printed to stdout.

On average, 20% of the perl4 .ph files, and 30% of the perl5 .ph files,
didn't evaluate cleanly.  Granted, a lot of these we don't care about.
(Trying to 'require "MovieController.ph"' on an SGI complains

    Can't locate X11/Xatom.ph in @INC (did you run h2ph?)

for example, but I can't imagine anyone wanting to use this header.)

Some of the headers, though, are useful.  For example, resolv.ph is used
by marc's resolv.pl library.  Unfortunately, perl5 either dies when
trying to eval resolv.ph (IRIX (and NetBSD)), or produces undesirable
warning messages as it attempts to cope (Solaris (and Linux)).  And
sys/types.ph is used by the (standardly distributed) perl5 module
Sys::Hostname, yet sys/types.ph doesn't eval cleanly under IRIX.

I'm not sure what to do about the errors.  I could
 - Give up on using version 5 of Perl, and just stick to version 4
   from the "perl" locker (at least I know it'll be stable).
 - Try to send patches to perldev for individual .ph files that
   I care about, and watch it all get wiped out a year from now
   when the perl5 locker is updated with a newer version of Perl.
 - Send patches to testers or bugs for individual .ph files that
   I care about, in the hope that the fixes will enter the Athena
   tree and become more or less permanent.
 - Give up on tying to use Perl for anything fancy, since .ph files
   are too fragile to be trusted.


I'll probably choose the third option, but felt like talking out loud
in case anyone else had opinions about what might be a better way
to handle this.

 -Jacob

home help back first fref pref prev next nref lref last post