Re: [PATCH] h2ph, etc.

Kurt D. Starsinic wrote:

>    The following patch:
>
>        Adds a test, h2ph_thorough, that compares constants available in
>        POSIX.pm and Socket.pm to their equivalents as generated by h2ph.

Great idea.

>+    chdir '..' if -d '../pod' && -d '../t';
>+    @INC    = 'lib';
>+    require Cwd;
>+    $Tmp    = Cwd::cwd() . "/t/tmp";
>+    -e $Tmp or mkdir $Tmp, 0777;
>+    push @INC, $Tmp;

It seems odd that you would jump through the portability hoop of calling
Cwd::cwd() (rather than say `pwd`) but then string concat that on unixy
/t/tmp dir specs.  This code as is won't do what you want on Mac OS nor
VMS were, e.g.:

 $ show default
  DRA3:[PERL]
 $ perl "-MCwd" -e "print Cwd::cwd()"
 DRA3:[PERL]

tacking on a "/t/tmp" to the end of that expression would result in a
MIXED native and unixy spec like 'DRA3:[PERL]/t/tmp' which vms perl cannot
grok.  I would recommend using File::Spec->catdir() rather than simple
string concatenation, as in this example from a VMS one liner:

$ perl "-MCwd" "-MFile::Spec" -e "print File::Spec ->catdir(Cwd::cwd(),'t','tmp')"
DRA3:[PERL.t.tmp]

the result of 'DRA3:[PERL.t.tmp]' is a valid directory spec in native VMS
speak.

Note however that one of the tests already makes a t/tmp/ directory,
namely t/io/fs.t and does not appear to need to C<chdir '..'> (which might
mess up other tests if h2ph_thorough.t were to fail or hang). However fs.t
is not exactly a paragon of portable perl (indeed it is a bunch of
disparate native shell hacks wrappered in perl backtick :-(

> +if (@ARGV and $ARGV[0] eq '-q') {
> +    shift @ARGV;
> +    open OK, '>/dev/null';  # XXX What's the portable way?
> +} else {
> +    open OK, '>-';
> +}

Here again perl's system independent File::Spec abstraction could assist
with portability concerns.  For example on VMS:

 $ perl "-MFile::Spec" -e "print File::Spec -> devnull"
 _NLA0:

Much better than /dev/null (the misleading thing about using /dev/null is
that it will work on anything that vaguely resembles unix - including
Cygwin on Windows and perhaps EMX on OS/2).


> +# STDERR will catch error output from utils/h2ph invocations (below):
> +open STDERR, ">$Tmp/h2ph.out";

That could work on VMS, Windows, etc. perhaps even Mac OS.  But on VMS and
Mac OS it might not create an h2ph.out file within a $Tmp sub-directory.
On Mac OS it woud create a file name $Tmp/h2ph.out in the current
directory (provided that the length of the whole thing did not exceed 31
characters.  Here again File::Spec could prove handy:

$ perl "-MCwd" "-MFile::Spec" -e -
 "$Tmp=File::Spec->catdir(Cwd::cwd(),'t','tmp');print File::Spec->catfile($Tmp,'h2ph.out')"
DRA3:[PERL.t.tmp]h2ph.out

that would be closer to what you want (note that on VMS you could have
gotten away with '/DRA3/PERL/t/tmp/h2ph.out' but that
'DRA3:[PERL.t.tmp]/h2ph.out' would have raised a fatal exception for being
an invalid file specification.

>  system
>+        './perl', '-Ilib', 'utils/h2ph',

this won't work on VMS where utils/h2ph.PL extracts itself into
utils/h2ph.com.  Look at the other h2ph, try using $^X rather than
'./perl'.  (That said the test is unlikely to succeed on VMS even if you
did that since by default C headers are in text library files such as
DECC$RTLDEF.TLB hence running h2ph _requires_ the extraction of loose
headers - but this is only an option for installing DEC C on VMS.)

One other thing to consider:

> +lib/h2ph_thorough.t            Really hammer h2ph

wouldn't a name like 'h2phcnst.t' (or what have you) be a bit more 8.3
friendly?

Thanks.

Peter Prymmer

• [PATCH] h2ph, etc. by Kurt D. Starsinic
• Re: [PATCH] h2ph, etc. by Peter Prymmer
• Re: [PATCH] h2ph, etc. by Michael G Schwern
• Re: [PATCH] h2ph, etc. by Kurt D. Starsinic
• Re: [PATCH] h2ph, etc. by Nick Ing-Simmons
• Re: [PATCH] h2ph, etc. by Kurt D. Starsinic