Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Re: RFC: Changing Perl Config settings

by Corion (Patriarch)
on Feb 22, 2008 at 09:07 UTC ( #669490=note: print w/replies, xml ) Need Help??

in reply to Changing Perl Config settings

Are these settings really complied into the executable?

On Windows, they aren't, because on Windows, it's possible for an executable to find out where its file lives. Perl uses that capability of Windows to populate its @INC.

Are these hidden paths part of what makes compliling Perl modules painful in windows? (testing with Glib and GTK indicate yes!)

These are the same hidden paths that make compiling libraries painful everywhere. You need to set up $ENV{INCLUDE} and $ENV{LIB} correctly. For Strawberry 5.10.0, I attach the path.cmd file I use to set up the environment for it below.

I think I've made a flash drive with a portable Perl installation ...which totally subverts a Windows PC's own Perl installation...

Which is how I manage the various versions of Perl I have on various machines too. Every Perl directory has a path.cmd which sets up the environment so that perl.exe is the "correct" Perl for that application and all other tools are also the correct versions. I use different versions of Perl for historical reasons, mostly because the applications using it Just Work and I don't want to invest the time to consolidate them all to a single Perl.

set BASE=%~dp0 path %BASE%perl\bin;%BASE%c\bin;%PATH% set INCLUDE=%BASE%c\include;%INCLUDE% set LIB=%BASE%c\lib;%LIB%

Replies are listed 'Best First'.
Re^2: RFC: Changing Perl Config settings
by Bloodrage (Monk) on Feb 22, 2008 at 09:18 UTC
    Snap. This is my commandprompt.bat that's executed when I open my command prompt. As you can see it's all there. U3_DEVICE_PATH is set by Command Prompt Portable, and is the current drive letter of my flash drive.
    @echo off color 07 prompt $p$g title Command Prompt Portable cls ver echo Setting Path to other files path %U3_DEVICE_PATH%\usr\bin;%PATH% set LIB=%U3DEVICE_PATH%\usr\lib;%LIB% set INCLUDE=%U3DEVICE_PATH%\usr\include;%INCLUDE% echo Setting Path to Strawberry Perl path %U3_DEVICE_PATH%\strawberry\c\bin;%U3_DEVICE_PATH%\strawberry\per +l\bin;%PATH% set LIB=%U3_DEVICE_PATH%\strawberry\c\lib;%U3_DEVICE_PATH%\strawberry\ +perl\bin;%LIB% set INCLUDE=%U3_DEVICE_PATH%\strawberry\c\include;%U3_DEVICE_PATH%\str +awberry\perl\lib\CORE;%INCLUDE% echo Setting Path to GTK+ path %U3_DEVICE_PATH%\GTK\bin;%PATH% set LIB=%U3_DEVICE_PATH%\GTK\lib;%LIB% set INCLUDE=%U3_DEVICE_PATH%\System\GTK\INCLUDE;%U3_DEVICE_PATH%\Syste +m\GTK\INCLUDE\GTK-2.0;%U3_DEVICE_PATH%\System\GTK\INCLUDE\GLIB-2.0;%U +3_DEVICE_PATH%\System\GTK\INCLUDE\PANGO-1.0;%U3_DEVICE_PATH%\System\G +TK\INCLUDE\CAIRO;%U3_DEVICE_PATH%\System\GTK\INCLUDE\ATK-1.0;%U3_DEVI +CE_PATH%\System\GTK\INCLUDE\GTKGLEXT-1.0;%U3_DEVICE_PATH%\System\GTK\ +LIB\GTK-2.0\INCLUDE;%U3_DEVICE_PATH%\System\GTK\LIB\GLIB-2.0\INCLUDE; +%U3_DEVICE_PATH%\System\GTK\LIB\GTKGLEXT-1.0\INCLUDE;%U3_DEVICE_PATH% +\System\GTK\INCLUDE\LIBGLADE-2.0;%U3_DEVICE_PATH%\System\GTK\INCLUDE\ +LIBXML2;%INCLUDE% set GTK_BASEPATH=%U3_DEVICE_PATH%\GTK set PKG_CONFIG_PATH=%U3_DEVICE_PATH%\GTK\lib\pkgconfig echo Setting Path to Cygwin path %U3_DEVICE_PATH%\cygwin\bin;%PATH% echo Update CPAN config file perl %U3_DEVICE_PATH%\system\bin\ cd\
Re^2: RFC: Changing Perl Config settings
by Bloodrage (Monk) on Feb 23, 2008 at 00:36 UTC
    A simple test script tells me that my $ENV{'INCLUDE'} environment variable is full of directories, which aren't being passed to the compiler via Perl or CPAN... ...I think I need to rewrite my script to build an @include from $ENV{'INCLUDE'}, but this is why I needed meditate on it :)
    use strict; use warnings; my @include = @INC; print '@INC =('.(join ",", @include).")\n\n"; print '%INCLUDE%=('.$ENV{'INCLUDE'}.")\n";
    Gives the following output:
    I:\Documents\Perl\U3 Perl Config scripts>perl @INC =(I:/strawberry/perl/lib,I:/strawberry/perl/site/lib,.) %INCLUDE%=(I:\System\GTK\INCLUDE;I:\System\GTK\INCLUDE\GTK-2.0;I:\Syst +em\GTK\INC LUDE\GLIB-2.0;I:\System\GTK\INCLUDE\PANGO-1.0;I:\System\GTK\INCLUDE\CA +IRO;I:\Sys tem\GTK\INCLUDE\ATK-1.0;I:\System\GTK\INCLUDE\GTKGLEXT-1.0;I:\System\G +TK\LIB\GTK -2.0\INCLUDE;I:\System\GTK\LIB\GLIB-2.0\INCLUDE;I:\System\GTK\LIB\GTKG +LEXT-1.0\I NCLUDE;I:\System\GTK\INCLUDE\LIBGLADE-2.0;I:\System\GTK\INCLUDE\LIBXML +2;I:\straw berry\c\include;I:\strawberry\perl\lib\CORE;\usr\include;C:\System\GTK +\INCLUDE;C :\System\GTK\INCLUDE\GTK-2.0;C:\System\GTK\INCLUDE\GLIB-2.0;C:\System\ +GTK\INCLUD E\PANGO-1.0;C:\System\GTK\INCLUDE\CAIRO;C:\System\GTK\INCLUDE\ATK-1.0; +C:\System\ GTK\INCLUDE\GTKGLEXT-1.0;C:\System\GTK\LIB\GTK-2.0\INCLUDE;C:\System\G +TK\LIB\GLI B-2.0\INCLUDE;C:\System\GTK\LIB\GTKGLEXT-1.0\INCLUDE;C:\System\GTK\INC +LUDE\LIBGL ADE-2.0;C:\System\GTK\INCLUDE\LIBXML2;c:\system\usr\include)

    I'm not entirely sure what this is telling me about the relationship of @INC and $ENV{'INCLUDE'}. One seems to be where Perl looks for Perly libraries... which may be set wrong, and the other is as I expect it to be configured and should point the compiler to all the appropriate include directories.

    Note: The I:\ prefixed paths have beens set up by my command prompt script, while the C:\ based paths are from my computer's original environment variables.

      @INC is where Perl looks for *.pm files.

      $ENV{INCLUDE} is where the C compiler looks for *.h and *.c files.

      The two bear little to no relation to each other.

        Ya, thanks. I had figured|rememberd that eventually. I'm beginning to think my include library is incomplete (the module Glib-1.164p still won't compile), but my program does seem to help Perl and it's modules find things easier.

        The program's been updated and now uses $ENV{'INCLUDE'} as the source of include directories, so I only have to maintain the include paths list in one place.

Re^2: RFC: Changing Perl Config settings
by syphilis (Archbishop) on Feb 24, 2008 at 00:15 UTC
    set INCLUDE=%BASE%c\include;%INCLUDE% set LIB=%BASE%c\lib;%LIB%

    That's interesting. I've noticed that Strawberry sets those two environment variables, but I've never understood why. Afaict, with MinGW (including Strawberry's MinGW), the compiler and linker search those locations by default. In fact, I've unset those 2 envvars, and everything still works fine:
    C:\_32\C>set LIB LIB= C:\_32\C>set INCLUDE INCLUDE= C:\_32\C>type try.c #include <stdio.h> int main(void) { printf("Hello from strawberry\n"); return 0; } C:\_32\C>gcc -o try.exe try.c C:\_32\C>try Hello from strawberry C:\_32\C>
    Similarly, if I'm building a perl extension using Strawberry Perl, the standard headers and libraries get found fine - even though those 2 envvars are unset. Perhaps those 2 envvars could be useful when it comes to finding headers and libraries that are stored in non-default locations. (I haven't tried that. I prefer to keep LIB and INCLUDE unset, and provide the non-standard locations with the -I and -L switches.)

    Update: I've since found time to take a closer look - and I can find no evidence that MinGW and Strawberry Perl take any notice at all of the INCLUDE and LIB environment variables. Visual Studio certainly does ... but not MinGW.


      Fantastic, so I wasn't imagining things when I thought things weren't working as they should. It looks like I need to spend some time getting MinGW to compile some things outside the CPAN shell. It also explains why my program helps, because it explictly sets the -I and -L switches when it reconfigures CPAN's

      I'm now considering the benefits of flattening my include directory structures into X:\strawberry\c\include rather than to have one for a) strawberry, b) GTK/Glade/Glib/Cairo... and c) a usr/include dir for 'one off' libraries. The current multiple include locations has the advantage of being able to update one without breaking the others, where the flattened version may result in overwriting 'good' with 'bad' when installing new material.

      PS: I think I can circumvent the difficulty compiling GTK2-Perl by manually installing the ActivState PPM... except I don't want this compiling issue to continue being a PITA when in the field with this portable Perl-onna-stick thing.

        by manually installing the ActivState PPM ...

        There's also the CPAN version of PPM which doesn't have all the whizz-bang-u-bute features of ActiveState's proprietary PPM - but it's quite functional. (There's a patch that enables it to handle zipped binaries, so that the ppm packages at the trouchelle rep are also accessible.)


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://669490]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (2)
As of 2022-05-28 07:58 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (98 votes). Check out past polls.