in reply to Re^7: Disappointed with latest Strawberry Perl
in thread Disappointed with latest Strawberry Perl

I have no experience with building Tk in a windows-only environment, because I always use Cygwin, with full X11 installed, and ActivePerl comes with Tk bundled, so I have no need to build myself. As Strawberry obviously is a similar build to ASperl ($^O - wise that is), adding MSWin32 can do no harm.

Anyway, by now I really hate the title of this thread, as I value Strawberry more and more with every experience. It is all doable. At least for me. I'm just sharing my experiences here hoping the product will get even better with the next build.

I can understand your point of seeing Tk as bloat to Strawberry, and if the new CPAN option solves that, I would not miss it, as building it with cpan then will yield no additional problems.

Is there any reason why the install path for Strawberry is fixed at C:\Strawberry? I have those utils at D: normally, and I can imagine a network share as install path so all can share it's beauty without having to install it.


Enjoy, Have FUN! H.Merijn
  • Comment on Re^8: Disappointed with latest Strawberry Perl

Replies are listed 'Best First'.
Re^9: Disappointed with latest Strawberry Perl
by Corion (Patriarch) on Dec 31, 2007 at 10:11 UTC

    It's only the path where the installer insists on putting Strawberry Perl. You can (after "installation") simply move the directory and patch Config.pm and Config_heavy.pl and CPAN/Config.pm to point to the new directory. I think the fixed installation mostly stems from some weird belief that executables (and especially Perl) are not relocatable by default on Win32.

    You will of course need to change $ENV{INCLUDE}, $ENV{LIB} and $ENV{PATH} to reflect the new location as well, but as you're setting up your own environment anyway, that should be no problem either.

[reply]
      I think the fixed installation mostly stems from some weird belief that executables (and especially Perl) are not relocatable by default on Win32.

      Unless I'm missing something, it's almost completely undocumented short of examining the source code.

      Prompted by your post, from a little experimention and source code browsing in win32/win32.c, it looks like on Windows, perl.exe automatically sets @INC relative to $^X. However, most of the Perl toolchain looks to Config.pm and Config_heavy.pl to determine the right directories for various library paths, which is why things break oddly just moving the directory without patching those files. (I think that is what you're describing is the case.)

      Given that, it should be fairly easy to patch Config.pm and Config_heavy.pl to just set the library paths similarly by looking relative to $^X

      It also looks like perl.exe uses the long path for $^X and the derived pathnames. I wonder if those were the short pathnames instead whether things would work better if Perl were installed in places like "C:\Program Files\perl"?

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
        it should be fairly easy to patch Config.pm and Config_heavy.pl to just set the library paths similarly by looking relative to $^X

        I've done that a few times myself. It is, as you suggest, just a matter of hunting through Config.pm and Config_heavy.pl and replacing every occurrence of C:\original\location with D:\new\location (or whatever). Doing it manually (which is the only way I've ever done it) is a little tedious, but only takes a few minutes. As you've noted, @INC is self-adjusting, so there's no problem in that regard.

        Cheers,
        Rob
        Update: Ooops ... I now think xdg might have been suggesting something else than merely editing Config.pm and Config_heavy.pl.
[reply]
[reply]

In Section Meditations