http://www.perlmonks.org?node_id=1145159


in reply to RFC: (Do Not) Modify the System Perl

The cons both strike me as partly to mostly false. If you use *anything* other than pure vanilla, feature-free Perl you’ll need to include the distribution or build it. RedHat’s brain dead 5.8 that had a slowdown of a thousand-fold on some kinds of object creation because they used their own non-standard build flags comes to mind. The packaging requirements are already more complex if you’re doing things right and if you’re already doing things right… then it’s not more complex. :P

  • Comment on Re: RFC: (Do Not) Modify the System Perl

Replies are listed 'Best First'.
Re^2: RFC: (Do Not) Modify the System Perl
by shmem (Chancellor) on Oct 17, 2015 at 19:48 UTC
    If you use *anything* other than pure vanilla, feature-free Perl you’ll need to include the distribution or build it.

    There's no such thing as a pure vanilla, feature-free Perl. Perl's Configure is full of featuritis and hints, and some features may well not be turned on in your vendor's perl. If I need e.g. -DDEBUGGING on my platform, yes, I have to rebuild perl - but I rebuild it as close to the platforms procedures as possible, i.e. only altering that switch in the build process. Otherwise I would just be asking for problems - asking the platform for them, that is, not perl.

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'