Front page | perl.perl5.porters |
Postings from December 2019
On 12/17/19 9:18 AM, Eric Wong wrote: >> On Mon, Dec 16, 2019 at 2:51 PM Eric Wong <p5p@yhbt.net> wrote: >> >>> Hello all, I noticed POSIX.pod states it's for IEEE Std 1003.1, >>> but I figure it'll be useful to support new functionality... > Hi Mark, Dan; thanks for the responses so far. > > Some background here: most users of my software get Perl from > their GNU/Linux distros or BSD ports. And a big reason why I > choose Perl is that it's widely available out-of-the-box and > users typically don't need to install extra dependencies. > > CPAN modules which aren't packaged by the distro are extra > overhead for them to learn, download and install; and they > already complain about dependencies. Most of them are not Perl > hackers. Even getting them to consider using software written > in Perl these days is a challenge :< > > Mark Overmeer <mark@overmeer.net> wrote: >> There are about 1800 functions in the 2008 release. POSIX.pm >> and CORE together support about 100 (but also not really strict) >> >> There are some modules on CPAN which implement some additional >> functions. A few dozen. > Right, some are abandoned and most of those are not available > from distros. > >> I started POSIX::1003 which tries to provide all functions... as >> pure as feasible. But... I need to rework it into a more flexible >> installation structure using Config::AutoConf. Help welcome ;-) >> When I get help, I will increase its priority. > Any reason you choose to work on a new module rather than > improving the existing POSIX one? I certainly don't see the > need for all functions in POSIX, especially the ones which > are made redundant by CORE functions. > > Dan Book <grinnz@gmail.com> wrote: >> If it's at all helpful, it's trivial to write a FFI::Platypus wrapper of >> POSIX functions available on the system, such as I did in Unix::Groups::FFI. > Yup. I favor Inline(::C) since it's more widely-packaged > (for example, perl-Inline is in CentOS/RHEL 7.x and AFAIK > Platypus is not). > > I may even favor syscall() for popular platforms since there's > no extra .so loading and no need to have a compiler installed. > > But I consider those dependencies interim solutions because of > the extra installation burden it places on users (and distro > maintainers). And this probably a big reason why AOT-compiled > languages like Go with giant binaries are gaining favor > nowadays. Is it not possible to go the path that Mark suggests by compiling a big Perl binary with the additional modules?Thread Previous | Thread Next