in reply to Windows precompiled binaries or DIY compile

Is it better to use a "packaged" easily installable version of Perl such as Strawberry on a Windows OS or to compile a version or there is no practical difference, etc...?

Perl 5.38.0 builds easily on Windows, and "straight out of the box" - using either Visual Studio 2022 or mingw-w64 ports of gcc-12 or gcc-13 (available from https://winlibs.com).
But I doubt that you'll get any advantage (in either speed or reliability) by using a perl that was built on your own machine.

The main thing you'll get by building perl yourself is the opportunity to have a perl that's configured the way you want.
For example, if you're not wanting to use either the fork() function or threads, you could build your own unthreaded perl - which, I believe, does provide a measurable improvement in speed.
For example, if (as I do) you want a perl that has an nvtype of __float128, then you'll have to build that perl yourself.

There are also considerations to be made in your choice of compiler.
For example, VS2022 builds of perl-5.38.0 support utf8 locales that StrawberryPerl doesn't.

The main advantage of Strawberry Perl is that it comes with a large range of additional modules, many of which rely on 3rd party libraries.
A perl that you build from source won't include those modules (which populate Strawberry's perl/vendor/lib directory).

The more people that build perl (including the monthly devel releases) on Windows, the better it is for perl.
One simple way is to start by editing the (self-documenting) perl-5.38.0/win32/GNUmakefile (or perl-5.38.0/win32 Makefile if building with MS Visual Studio).
All you really need do is:
1) Ensure that INST_DRV and INST_TOP specify the location in which you want perl to be installed;
2) For gcc builds, uncomment the line #CCTYPE        := GCC; for VS2022 builds, uncomment the line #CCTYPE        = MSVC143;
3) For gcc builds, uncomment the line #CCHOME        := C:\MinGW and edit it to specify the directory that contains gcc's bin directory.
That should build you a perl that is configured essentially the same as Strawberry Perl.

Then, cd to the perl-5.38.0/win32 folder and run:
1) gmake test (or nmake test for Visual Studio builds).
2) gmake install (or nmake install).

Following that, if you wish to re-use the same source to build a different configuration of perl, first run gmake distclean or nmake distclean.
Any problems, just ask.

Cheers,
Rob.

Replies are listed 'Best First'.
Re^2: Windows precompiled binaries or DIY compile
by eyepopslikeamosquito (Archbishop) on Sep 24, 2023 at 02:48 UTC

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

    As strongly cautioned by Fletch:

    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. :)

[reply]

      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]

In Section Seekers of Perl Wisdom