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

I am attempting to set up a Perl build system in a non-writable environment (ClearCase VOB). Basically, I have a set of makefiles that incrementally builds the final distribution from the following pieces:
  1. Support libraries (gdbm, expat, zlib)
  2. Perl 5.8.0
  3. Additional CPAN modules

I build each piece in order, installing into a 'dist' subdirectory, which is not the final installation directory. Confused? I am. All of the packages are built as though the installation will be into /usr/local/lib, /usr/local/perl5, but using makefile trickery or Perl Configure's -Dinstallprefix, things are installed into .../myvob/src/dist/lib, .../myvob/src/dist/perl5.

I can manage to get the libraries and Perl itself to install into this directory structure, and have them *think* they ar e installed in /usr/local. The rub is in getting the CPAN modules to build using the 'dist' version of Perl.

For instance, trying to install Config::IniFiles, I get the following error:

Checking if your kit is complete...
Looks good

Error: Unable to locate installed Perl libraries or Perl source code.

It is recommended that you install perl in a standard location before
building extensions. Some precompiled versions of perl do not contain
these header files, so you cannot build extensions. In such a case,
please build and install your perl from a fresh perl distribution. It
usually solves this kind of problem.

(You get this message, because MakeMaker could not find "/usr/local/pe
+rl5/lib/5.8.0/sun4-solaris-64int/CORE/perl.h")

[download]

I need the modules to utilize the Perl core stuff from the 'dist' directory, but without building binary dependencies on these paths. This is much the same as the Perl build's -Dprefix vs -Dinstallprefix. I can't figure out how to make Ext::MakeMaker to behave the same way!!!

Any help appreciated.

Edit by tye, change PRE to CODE

Replies are listed 'Best First'.
Re: Building Perl in a Non-standard environment
by defyance (Curate) on Mar 17, 2003 at 18:23 UTC
    Just a shot in the dark, not sure if this is what you want, but check this out:

    ExtUtils::MakeMaker Docs

    -- Can't never could do anything, so give me and inch, I'll make it a mile.

[reply]

      I had tried this, but the build still complains that it cannot find perl.h. The perl executable *thinks* it is installed in /usr/local/perl5, but actually there is nothing there. I cannot install into this directory, because I don't have root permission on the ClearCase server.

      What I need is a way to tell the module to use $(dist)/perl5 sub directories for build/install, but still keep internal stuff (like the #! path for LWP scripts) pointing to /usr/local/perl5/bin/perl. Perl lets me do this easily, but I can't figure out how to make the same thing happen using ExtUtils::MakeMaker...

[reply]
        Well, it's been over 4 years since I used ClearCase, but I vaguely remember having a similar problem. Unfortunately for you, I did have root on the build box, so the solution for me was to make /usr/local/perl5 (and other necessary places) into vob-exported directories (Is that the right term? It used a view to figure out what was there, but you didn't need to be in the view to see it).

        If you can't get root permission, perhaps your sysadms will give you a suid script that installs the (newly built) Perl in /usr/local/perl5/..., which you could then run after building perl but before building extentions.

        HTH,
        --roundboy

[reply]
Re: Building Perl in a Non-standard environment
by PodMaster (Abbot) on Mar 18, 2003 at 08:42 UTC
    Try perl -V:.*prefix.* -V:perlpath and see what you get back. If those values aren't correct, it means your Config.pm is messed up, and if you installed perl properly, that shouldn't be the case. ExtUtils::MakeMaker relies, like perl does, on Config.pm containing the correct information.

    MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
    I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
    ** The Third rule of perl club is a statement of fact: pod is sexy.

[reply]
[d/l]

      True story - unfortunately, I need a way of overriding where Config.pm (and the perl binary itself) think they are located. The only solution I could find to this was to just install perl into my VOB path, then adding -Dotherlibdirs to point to the perl5/lib and perl5/lib/site_perl directories in /usr/local. Downside is that the @INC path contains directories that will never exist on a target system, but that's minor for me...

      Of course I would prefer a cleaner alternative, and investigated stream editing the perl binary itself to remove a prefix string from all portions of the PERLLIB encoded in there. I can do this by hand, but it involves either space padding the beginning or end of the path elements with the same number of spaces as prefix characters removed. This has some strange consequences when modules attempt to use the @INC path, however. The most hardcore of efforts would involve updating the ELF header to account for the missing characters, but let's just say I'm not that motivated :).

      Rgds,
      C.

[reply]

Back to Seekers of Perl Wisdom