h2ph not rerun after perl5 upgrade

[vinc17@…]

When I upgraded perl5 to 5.12, the modules were automatically reinstalled as there revision was increased, but h2ph was not rerun (this is needed by p5-filesys-diskspace). Everything went apparently fine, without error messages, and this module silently became unusable for this obscure reason. It took me some time to debug this, as the error message when using this module was just:

Cannot use df on this machine (untested or unsupported).

The h2ph command should have been rerun or there should have been a clear message at the end.

[ghosthound]

No longer maintainer

[mojca (Mojca Miklavec)]

I would like to ask for more info about this.

[mojca (Mojca Miklavec)]

geekosaur at IRC:

Basically h2ph for a perl version should be run in the postinstall for that perl version. This "translates" system header files to perl, producing pack templates for structs used by syscalls / libraries

In theory you could run it as part of packaging it for a given macOS release, but that courts license issues (those files are covered not by the perl license but the OS license)

Typical usage is:

cd /usr/include; h2ph -r -l .

(which translates all the translatable headers, recursively, installing the result in the appropriate perl site packages dir)

If perl is built universally, the result is different.

[mojca (Mojca Miklavec)]

I would be inclined to (not) "fix" this issue by adding notes telling users to run the command manually, or simply not do anything at all. It's not clear to me which files to process at all. Users might upgrade Xcode in the meantime, they might need files of their own C(++) headers. Most users likely don't need any of that. I've only ever seen this one single request from any user and this one dates back to 5 years ago. I'm sure this is still an issue, but I could imagine that doing any automatism would introduce many more problems than it would solve. I'm open to suggestions though.

[chrstphrchvz (Christopher Chavez)]

At the moment, p5-tcl-ptk requires sys/ioctl.ph to be generated for its fileevent to work at all. (ignore: its fileevent ​is broken indefinitely on macOS or any BSD derivative--not MacPorts' fault.)

Knowing which files h2ph needs to be run on for a distribution seems possible but likely requires inspecting the source code of the distribution (e.g. finding any require "….ph"; statements).

This is a rare issue, but if this were needed more often, then rather than manually using h2ph from postinstall, it would probably more ideal to have something in the perl5 PortGroup handle this, something like perl5.h2ph sys/syscall.ph in the subport, in case an approach better than rerunning h2ph becomes possible, or headers move(?), etc. And unless there's a way to rerun h2ph when MacPorts detects XCode (if not the specific header file) was updated, the above concerns about compatibility still apply.