pmu has asked for the wisdom of the Perl Monks concerning the following question:

Respected Monks,

I am planning to build Perl off of Strawberry Perl (version 5.16.3) for the following reasons:

1) The current project that I am in has management servers that have Activestate Perl version 5.12 pre installed, but there are many Perl scripts which depend on it. I am treating it as a "System Perl" and do not want to fiddle with it. Access to the outside world is disabled from those servers. Hence I cannot also install required modules on it.

2) A script I had created in my earlier project heavily depends on Net::SSH2, MIME::Lite, Config::Tiny, Excel::Writer::XLSX and couple other modules that do not come pre installed with Strawberry Perl.

3) I want to use this opportunity to be able know how to build perl based off of Strawberry.

As of now I am referring - http://strawberryperl.com/documentation/building.html and will try to build it over this weekend , but I will be extremely thankful if someone has already done this and could provide some extra pointers/documentation.

Edit: Kindly note that I will be building off of 32 bit Perl. My laptop is running on 64 Bit Windows 7, but the servers are 32 bit Windows 2003 Servers. Any precautions that I need to take? Any gotchas that I'll have to watch out for?

|| Aeterna Est Perspectum Cognitio ||
  • Comment on Pointers for building Perl off of Strawberry Perl.

Replies are listed 'Best First'.
Re: Pointers for building Perl off of Strawberry Perl.
by syphilis (Archbishop) on Jan 17, 2014 at 02:55 UTC
    I take it you're considering building perl using the tools (dmake and gcc) that ship with Strawberry Perl.
    To do so is fairly straightforward:
    1) Download and extract the perl source;
    2) Edit the Win32/makefile.mk to suit your needs;
    3) Then cd to Win32 directory and run 'dmake', 'dmake test' and 'dmake install'.

    As regards the editing, the makefile.mk is pretty much self-documenting.
    For a perl that's compatible with Strawberry Perl you'll want to set INST_DRV and INST_TOP to wherever you want perl to be installed, uncomment the "#WIN64 *= undef" entry (because you're building a 32-bit perl on a 64-bit OS), and change the CCHOME entry to the location of gcc.
    If you're building 5.18.0 or later uncomment the "#USE_64_BIT_INT *= define" entry.
    If you want to build some perl modules against any of the C libraries that ship with Strawberry Perl in c/lib, then specify that (fully qualified) c/lib location in EXTRALIBDIRS - then those libraries will be found when you link to them.
    Similarly, you might have other C libraries that you need to use for the same purpose - specify their location(s) in EXTRALIBDIRS also.

    And that's about it. You may find that the test suite hangs during the running of 'dmake test'. (I always ignore that when it happens and just 'dmake install' anyway.)
    The perl that you build this way will differ from Strawberry Perl in that the various perl/lib/*DBM_File.pm modules will be absent. (I can't think of any other differences at the moment, though I suspect you might be missing some other modules that ship with Strawberry.)

    For specific details on the way that Strawberry is built, the strawberry mailing list is probably the best place.

    Cheers,
    Rob
[reply]

      Hi syphilis,

      Thank you for such a detailed answer. I have no words to thank you sir.

      || Aeterna Est Perspectum Cognitio ||
[reply]
Re: Pointers for building Perl off of Strawberry Perl.
by dasgar (Priest) on Jan 16, 2014 at 16:45 UTC

    I personally have not tried to build Strawberry Perl from source and therefore can't offer any guidance to help you, but one source to look for help would be the information on their support page.

    Depending on your needs and limitations, you might be able to use Strawberry Perl's portable version (see their releases page) which does not need to be "installed" or maybe develop the scripts on another system and use something like pp (from PAR::Packer) to package the Perl script into a stand-alone executable. Just thought I'd toss out a few ideas on alternatives.

[reply]
      Completely agree with both: using one of the stand-alone versions is an excellent idea, but if you're deploying stuff, Par::Packer works really well. I use it on a regular basis.

      32 bit ActiveState behaves on my 64 bit Win8 machine with no problems in any step of my dev/deploy activities. I'd expect Strawberry to behave much the same.

[reply]
Re: Pointers for building Perl off of Strawberry Perl.
by bulk88 (Priest) on Jan 17, 2014 at 05:11 UTC
    1) The current project that I am in has management servers that have Activestate Perl version 5.12 pre installed, but there are many Perl scripts which depend on it. I am treating it as a "System Perl" and do not want to fiddle with it. Access to the outside world is disabled from those servers. Hence I cannot also install required modules on it.

    If you can't install a module on the machine, you can't install a whole new Perl either. If there is zero outside access, then you will have to type all your modules in by hand from a printed copy of the .pm.

    Move the tarballs over and build them on the server, or see Yes, even you can use CPAN.
[reply]
Re: Pointers for building Perl off of Strawberry Perl.
by pmu (Beadle) on Jan 16, 2014 at 17:56 UTC

    Respected Monks,

    Thank you for your replies. Will surely try out the options you mentioned. Will keep checking here if someone who has tried building strawberry perl can help.

    || Aeterna Est Perspectum Cognitio ||
[reply]
Re: Pointers for building Perl off of Strawberry Perl.
by Anonymous Monk on Jan 16, 2014 at 19:52 UTC
    Food for thought...

    If you're allowed to copy files to the machine from a portable media, put a copy of Strawberry portable on the media, use cpan/cpanm to install your modules, carry the media to the machine in question, and copy the Strawberry Portable directory across.

    Not elegant, but simple.

    TJD

[reply]
Re: Pointers for building Perl off of Strawberry Perl.
by pmu (Beadle) on Jan 17, 2014 at 18:14 UTC

    Respected Monks,

    Many thanks for your responses. This is why Perl and PerlMonks rocks.

    || Aeterna Est Perspectum Cognitio ||
[reply]

Back to Seekers of Perl Wisdom