On 7 February 2017 at 03:34, Alceu Rodrigues de Freitas Junior via
cpan-testers-discuss <cpan-testers-discuss@perl.org> wrote:
> I just released a new distribution
> (http://search.cpan.org/~arfreitas/Linux-NFS-BigDir-0.001/) but I see that
> is getting a lot of fails because h2ph is not configured.
There's a reasonable problem with general purpose h2ph if any of the
constants you depend upon from the system are implemented in terms of
"sizeof"
h2ph basically rewrites all calls to sizeof($argument) as
$sizeof{"$argument"}, and then leaves implementation of those sizeof
fields to the user... ( and then doesn't even warn when code uses
undefined sizeof values, and so just returns 0 ... which is almost
certainly wrong )[1]
Which creates a fun problem:
- You can't rely on h2ph because it has problems that can't be
answered without using a compiler
- You can't simply hardcode the constants yourself as they're
architecture dependent.
I've got a way around this downstream[2][3] by analysing the constants
people tend to need and running a bit of C code that generates the
right architecture-specific values on the end machine, but its not
really useful for upstream purposes.
It would be literally simpler to just write the necessary code
yourself in C and then ship that with your dist.
It seems icky because you have to rely on a compiler, but its kinda
tricky *not* to rely on a compiler.
Granted, as _long_ as you stick to Linux, and then restrict yourself
to a specific processor type, then simple values like the syscall-id
shouldn't change, as that's one of the things that Linux API has a
very hard line about[4], It may introduce new syscall-id values, or
cease responding to old ones, but ID-reuse doesn't seem to be a
problem.
But for anything else, the "more portable" solution is probably going
to require at least one call to a compiler somewhere.
1: https://rt.perl.org/Ticket/Display.html?id=127517
2: https://github.com/gentoo-perl/perl-headers/blob/master/specs/_h2ph_pre.c
3: Relatively untested because the demand for it is so incredibly low,
probably as a result of aforementioned limitations
4: http://man7.org/tlpi/api_changes/
--
Kent
KENTNL - https://metacpan.org/author/KENTNL
