=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilm...@ilmari.org> writes: > Tom Lane <t...@sss.pgh.pa.us> writes: >> gfortran? Really?? I mean, I don't care about the disk space, >> but this is not promising for anyone who has to build it themselves.
> The Fortran support for FFI::Platypus is in a separate CPAN distribution > (FFI-Platypus-Lang-Fortran), so that must be some quirk of the Fedora > packaging and not a problem for people building it themselves. Ah, they must've decided to combine FFI-Platypus-Lang-Fortran into the same RPM. Not quite as bad then, since clearly we don't need that. Another thing to worry about is whether it runs on the oldest perl versions we support. I tried it on a 5.14.0 installation, and it at least compiles and passes its self-test, so that's promising. "cpanm install FFI::Platypus" took about 5 minutes (on a 2012 mac mini, not the world's fastest machine). The list of dependencies it pulled in is still kinda long: Capture-Tiny-0.48 ExtUtils-ParseXS-3.51 Test-Simple-1.302195 constant-1.33 Scalar-List-Utils-1.63 Term-Table-0.017 Test2-Suite-0.000156 File-Which-1.27 FFI-CheckLib-0.31 Try-Tiny-0.31 Test-Fatal-0.017 Test-Needs-0.002010 Test-Warnings-0.032 URI-5.21 Algorithm-Diff-1.201 Text-Diff-1.45 Spiffy-0.46 Test-Base-0.89 Test-YAML-1.07 Test-Deep-1.204 YAML-1.30 File-chdir-0.1011 Path-Tiny-0.144 Alien-Build-2.80 Alien-Build-Plugin-Download-GitHub-0.10 Net-SSLeay-1.92 HTTP-Tiny-0.088 Mozilla-CA-20230821 IO-Socket-SSL-2.083 Mojo-DOM58-3.001 Alien-FFI-0.27 FFI-Platypus-2.08 A couple of these are things a buildfarm animal would need anyway, but on the whole it seems like this is pretty far up the food chain compared to our previous set of TAP dependencies (only three non-core-Perl modules). Still, writing our own equivalent is probably more work than it's worth, if this is a suitable solution in all other respects. Having said that ... I read the man page for FFI::Platypus, and I'm failing to draw a straight line between what it can do and what we need. Aren't we going to need a big chunk of new Perl code anyway? If so, why not write a big chunk of new Perl that doesn't have new external dependencies? regards, tom lane