Hello Kent,
Thanks for sharing all this info.
I guess it makes a lot of sense trying to use a compiler (that should be
available anyway on Linux to install Perl distributions) to get this
information.
The solution that comes to my mind it to write a small C program to
write down long size instead of using h2ph... it could write to the
__DATA__ section of the corresponding module, for example.
I'm no C programmer (so far), but I guess doing that in C should be
trivial. On the other hand It seems to be more complicate to integrate
that with Dist::Zilla (or Makefile.PL) since I would need to compile the
C program and execute it.
I guess Dist::Zilla might have a plugin to execute arbitrary OS
commands, but if you're aware of any standard way of doing that, please
let me know.
Regards,
- Alceu
Em 14/02/2017 02:17, Kent Fredric escreveu:
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/
