Re^2: Windows precompiled binaries or DIY compile

Thanks for that Rob! A really useful post that I will refer to often in the future.

If you're doing anything serious with Perl you DO NOT want to use the OS' perl as that way lies much pain. Doing so couples you tightly to the OS' upgrade schedule for both the language and (if you're using its package manager for them) CPAN modules.

Having supported and maintained large customer systems for many years on many different Unix flavours, I strongly agree with this advice. The last thing you want is to be flooded with support calls when a "harmless" customer OS update breaks the Perl scripts/modules used by your product!

AFAIK, Windows does not have an "OS Perl" ... so perhaps Strawberry Perl is the nearest thing to that ... and similar dependency considerations apply ... that is, a customer upgrading to a later version of Strawberry Perl may break the Perl scripts in your product ... so building and shipping your own Perl on Windows just got a lot more attractive to me. :)

Comment on Re^2: Windows precompiled binaries or DIY compile

Replies are listed 'Best First'.
Re^3: Windows precompiled binaries or DIY compile by NERDVANA (Priest) on Sep 27, 2023 at 22:01 UTC
The advice generally assumes that the OS package manager installed perl for lots of scripts and applications to share. That's a bad perl environment for a long-lived app that you want to keep running across OS upgrades. Windows itself does not have any reliance on Perl, and a Windows Update will never install a new perl version on you. It's equally unlikely that a windows update would break library dependencies of XS perl modules. Unless you have a whole lot of unrelated software on the same host all using perl, Strawberry is probably functioning more like perlbrew than like Unix /usr/bin/perl. That said, if you are "shipping" a perl application that you intend to be installed in its own `Program Files` path, then yes it should probably include its own perl interpreter compiled to use those paths and not interfere with anything else in the %PATH%	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: Windows precompiled binaries or DIY compile
by NERDVANA (Priest) on Sep 27, 2023 at 22:01 UTC

The advice generally assumes that the OS package manager installed perl for lots of scripts and applications to share. That's a bad perl environment for a long-lived app that you want to keep running across OS upgrades.

Windows itself does not have any reliance on Perl, and a Windows Update will never install a new perl version on you. It's equally unlikely that a windows update would break library dependencies of XS perl modules. Unless you have a whole lot of unrelated software on the same host all using perl, Strawberry is probably functioning more like perlbrew than like Unix /usr/bin/perl.

That said, if you are "shipping" a perl application that you intend to be installed in its own Program Files path, then yes it should probably include its own perl interpreter compiled to use those paths and not interfere with anything else in the %PATH%

[reply]
[d/l]