deprecate h2ph

[p5pRT]

Migrated from rt.perl.org#132576 (status was 'open')

Searchable as RT132576$

[p5pRT]

From zefram@fysh.org

Created by zefram@fysh.org

h2ph has a bunch of bugs that make it unreliable, and we are evidently
unable to maintain it in working condition. We should deprecate it.

h2ph would be no great loss. It was useful in its time, but it represents
a long-obsolete approach to integration with C libraries. There is no
need to maintain any form of this capability.

To manage the deprecation, not only should h2ph itself give a deprecation
warning when run, but it should also write into generated .ph files code
to generate a deprecation warning when the .ph is loaded.

Perl Info

Flags:
    category=utilities
    severity=low

Site configuration information for perl 5.27.6:

Configured by zefram at Tue Nov 21 05:42:59 GMT 2017.

Summary of my perl5 (revision 5 version 27 subversion 6) configuration:
   
  Platform:
    osname=linux
    osvers=3.16.0-4-amd64
    archname=x86_64-linux-thread-multi
    uname='linux barba.rous.org 3.16.0-4-amd64 #1 smp debian 3.16.43-2+deb8u2 (2017-06-26) x86_64 gnulinux '
    config_args='-des -Dprefix=/home/zefram/usr/perl/perl_install/perl-5.27.6-i64-f52 -Duselargefiles -Dusethreads -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dusedevel -Uversiononly -Ui_db'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=define
    usemultiplicity=define
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='cc'
    ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
    optimize='-O2'
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion=''
    gccversion='4.9.2'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='cc'
    ldflags =' -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
    libs=-lpthread -lnsl -ldb -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.19.so
    so=so
    useshrplib=true
    libperl=libperl.so
    gnulibc_version='2.19'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='-Wl,-E -Wl,-rpath,/home/zefram/usr/perl/perl_install/perl-5.27.6-i64-f52/lib/5.27.6/x86_64-linux-thread-multi/CORE'
    cccdlflags='-fPIC'
    lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong'



@INC for perl 5.27.6:
    /home/zefram/usr/perl/perl_install/perl-5.27.6-i64-f52/lib/site_perl/5.27.6/x86_64-linux-thread-multi
    /home/zefram/usr/perl/perl_install/perl-5.27.6-i64-f52/lib/site_perl/5.27.6
    /home/zefram/usr/perl/perl_install/perl-5.27.6-i64-f52/lib/5.27.6/x86_64-linux-thread-multi
    /home/zefram/usr/perl/perl_install/perl-5.27.6-i64-f52/lib/5.27.6


Environment for perl 5.27.6:
    HOME=/home/zefram
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/zefram/usr/perl/perl_install/perl-5.27.6-i64-f52/bin:/home/zefram/usr/perl/util:/home/zefram/pub/x86_64-unknown-linux-gnu/bin:/home/zefram/pub/common/bin:/usr/bin:/bin:/usr/local/bin:/usr/games
    PERLDOC=-oman
    PERL_BADLANG (unset)
    SHELL=/usr/bin/zsh

[p5pRT]

From @leonerd

On Tue, 12 Dec 2017 04​:23​:11 -0800
Zefram (via RT) <perlbug-followup@​perl.org> wrote​:

h2ph has a bunch of bugs that make it unreliable, and we are evidently
unable to maintain it in working condition. We should deprecate it.

h2ph would be no great loss. It was useful in its time, but it
represents a long-obsolete approach to integration with C libraries.
There is no need to maintain any form of this capability.

To manage the deprecation, not only should h2ph itself give a
deprecation warning when run, but it should also write into
generated .ph files code to generate a deprecation warning when
the .ph is loaded.

If you're looking for CPAN alternatives to suggest folks use instead,
might I at this point make a blatant plug for my own solution to this
kind of problem, ExtUtils​::H2PM​:

  https://metacpan.org/pod/ExtUtils::H2PM

An example of it being used is

  https://metacpan.org/source/PEVANS/Socket-Netlink-Route-0.05/lib/Socket/Netlink/Route_const.pm.PL

It isn't quite the same and doesn't work in quite the same manner, but
it aims to fit into roughly the same kinds of problems that `h2ph` did,
so it might be interesting enough for people to at least take a look at.

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk | https://metacpan.org/author/PEVANS
http​://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @cpansprout

On Tue, 12 Dec 2017 04​:23​:10 -0800, zefram@​fysh.org wrote​:

This is a bug report for perl from zefram@​fysh.org,
generated with the help of perlbug 1.41 running under perl 5.27.6.

-----------------------------------------------------------------
[Please describe your issue here]

h2ph has a bunch of bugs that make it unreliable, and we are evidently
unable to maintain it in working condition. We should deprecate it.

h2ph would be no great loss. It was useful in its time, but it
represents
a long-obsolete approach to integration with C libraries. There is no
need to maintain any form of this capability.

To manage the deprecation, not only should h2ph itself give a
deprecation
warning when run, but it should also write into generated .ph files
code
to generate a deprecation warning when the .ph is loaded.

Why would it need to go that far?

--

Father Chrysostomos

[p5pRT]

From zefram@fysh.org

Father Chrysostomos via RT wrote​:

Why would it need to go that far?

If .ph files are being generated with a version of h2ph new enough to have
the deprecation notice, that implies that the .ph is being regenerated
with every new core release. In that case the deprecation implies that
that regeneration process will shortly fail, and the .ph will likely
become unavailable. Hence any .ph generated with the deprecated h2ph
is itself tacitly deprecated. A .ph that doesn't get regenerated, otoh,
is fine and can continue in use getting neither better nor worse.

-zefram

[p5pRT]

From @eserte

Dana Tue, 12 Dec 2017 04​:23​:10 -0800, zefram@​fysh.org reče​:

...

h2ph has a bunch of bugs that make it unreliable, and we are evidently
unable to maintain it in working condition.

Can you add references (e.g. links to other RT tickets) mentioning the problems?

[p5pRT]

From zefram@fysh.org

slaven@​rezic.de via RT wrote​:

Can you add references (e.g. links to other RT tickets) mentioning the problems?

Sure. There are open bug reports [perl #34495], [perl #34497], and
[perl #98062]. As you can see, these are quite old, and are getting
little attention. In addition to those tickets, there's a long-standing
bug of h2ph putting sub declarations inside conditionals. Attempting to
fix the reported bugs is an unappealing task, not just because h2ph is
little used, but because what h2ph does is intrinsically pretty crazy,
and fixing bugs of any significance would require engaging with the
crazy and adding a bunch more of it. Conditional sub declarations are
easily fixed, but no one has done so despite it being easy. That shows
how little value people see in fixing h2ph.

-zefram

[p5pRT]

From @Leont

On Tue, Dec 12, 2017 at 1​:23 PM, Zefram <perlbug-followup@​perl.org> wrote​:

h2ph has a bunch of bugs that make it unreliable, and we are evidently
unable to maintain it in working condition. We should deprecate it.

h2ph would be no great loss. It was useful in its time, but it represents
a long-obsolete approach to integration with C libraries. There is no
need to maintain any form of this capability.

The thing is seriously flawed. Not so much by bad design, but by age. The
thing predates CPAN by about half a decade. That makes it hard to integrate
it into CPAN modules, limiting its use.

Debian ships with a whole bunch of these .ph files, and they're pretty
useful when wanting to access certain system features without needing a
compiler. We also have some documentation that's assuming those resuling
files are around (most obviously syscall).

I don't mind getting rid of this interface (I've been planning to make wrap
it in such a way that it plays nicely with CPAN, but I never got around to
it), but I do think it's useful to keep this functionality in one way or
another.

To manage the deprecation, not only should h2ph itself give a deprecation
warning when run, but it should also write into generated .ph files code
to generate a deprecation warning when the .ph is loaded.

That sounds more aggressive than strictly necessary to me. Especially
because the user of the .ph files may not be someone who can't fix this
issue.

Leon