Cpan fails on Windows

Perl
#1

Due to the lengthy build times, I’ve been experimenting with using cpan to install modules into an activated build.

The first problem I encountered was that cpan would fail on the dependency Win32::Console.

Now cpan works for some commands (like -D), but generates the messaging I’ve included below down below.

So I’m writing this while waiting another half hour to add dmake to the build.

My experience so far leads me to ask the following questions:

  1. Why do builds take so long, and the timing so variable? I’ve seen times vary from 20 minutes to an hour.

  2. Why isn’t there an incremental build option? (I read the document explaining why full builds are a best practice. Waiting an hour because you need 1 module … and then discover you need another and it costs you another hour … is hardly a “best practice” when it comes to developer productivity.)

  3. Why aren’t Win32::Console and dmake included in the core build, so cpan will work?

I think it should be up to me to decide whether I want to use ActiveState’s build infrastructure for everyday development. I don’t mind using it to create a base build, but I’d sure like to be able to install modules whenever I need them.

It looks like you don't have a C compiler and make utility installed.  Trying
to install dmake and the MinGW gcc compiler using the Perl Package Manager.
This may take a a few minutes...

No Perl script found in input

It looks like the installation of dmake and MinGW has failed.  You will not
be able to run Makefile commands or compile C extension code.  Please check
your internet connection and your proxy settings!

Use of uninitialized value in pattern match (m//) at C:\Users\jgpuckering\AppData\Local\activestate\fb77abb1\site\lib/ExtUtils/MM_Win32.pm line 40.
Use of uninitialized value in pattern match (m//) at C:\Users\jgpuckering\AppData\Local\activestate\fb77abb1\site\lib/ExtUtils/MM_Win32.pm line 41.
Use of uninitialized value in pattern match (m//) at C:\Users\jgpuckering\AppData\Local\activestate\fb77abb1\site\lib/ExtUtils/MM_Win32.pm line 42.
Loading internal logger. Log::Log4perl recommended for better logging
#2

Hi @jgpuckering!

Thanks for writing! I’ll drop a few notes in, but may need our dev team to correct some of my answers (as I’m only a lapsed old PHP developer.) :smiley:

What version of Perl are you building? Versions prior to Perl 5.32 are a bit slow. Build time is variable based on availability of resources, whether or not a particular asset is cached, etc. Perl 5.32.x should be much, much faster as it used a new, improved system. You can read about it here: https://www.activestate.com/blog/dependency-resolution-optimization-activestates-approach/

This new solver also handles incremental builds in a sensible way.

As for why we don’t ship the tools needed to build on your local system, it would be very hard to make the builds replicable if we did that. As the system is architected, you can share your project with others and be sure that they’ll be getting the same thing. That’s a feature of the system, rather than a bug. If each dev can build individual packages on their system, that feature of the system breaks.

Cheers!
–zak

#3

Thanks for your reply.

I’ve been building 5.28.1. I will try 5.32, but my client is looking to migrate first to 5.28 rather than jump to the most current release. I’ll need to understand the quality and stability of 5.32 more than I do right now before recommending they jump to it. They are currently on 5.24.

So far, any time I’ve modified dependencies on 5.28 builds it has triggered a full rebuild. I’ll experiment with 5.32 and see what happens.

Regards,

  • Gary
#4

Hi @jgpuckering ,

Just following up with what Zak comments… I think you’ll find most of the issues you raised here resolved with 5.32. We’re pretty close to removing the beta label on it and dropping community support for Perl 5.26 and Perl 5.28. You’ll find it dramatically faster (it actually builds incrementally and in parallel on our build farm) and it has access to the most of the CPAN catalog. But do note that the installation process has changed as we’re deprecating installers in favor of our APIs and Open Source Command line tool. So be aware that the entire workflow is different than what you’re accustom to. We think you’ll find it superior, but if that’s not the case let us know how we can improve … delivering tools that work for the community is a priority for us.

To answer why we’re making all the changes you’re seeing and can’t build locally… . We are in the midst of reinventing package management for teams that works universally across language eco systems as well as operating systems. It’s a tall task. Key component to pull that off is… build reproducibility which require hermetically sealed build environments. We’ll eventually tackle that for local systems but before we get there we want to backport all our old Perl versions to the new system and release support for contributing to the catalog (you’ll be able to customize how builds are done w/o waiting on us). We’re on track to do both this year which is when we’ll finally reach the “Minimum Lovable Product” stage for our platform.

Appreciate your willingness to experiment with Perl 5.32! All our development effort is focused there so you’ll find the team most responsive to that feedback and you’ll have the greatest influence.

Best of Luck on your adventures! Looking forward to helping you out!

2 Likes