Forigve me... Would this var be in the ASSP code, or in the perl mod?
I would be more than happy to track it down, but I do not fully
understand how this @INC variable works.
On Jan 22, 2009, at 7:29 PM, Frank J. R. Hanstick wrote:
Hello,
In that the variable acts two different ways in two different
locations, I would look to where the variable is set and for where
the setting may change or for a broken link that causes @INC to be
used as a local variable instead of a global.
Frank
On Jan 22, 2009, at 12:41 PM, Scott Haneda wrote:
I have this solved, but I do not know how to solve this in a way
that works for MacPorts. I am assuming there is a solution for the
issues, since it seems it would be common to many perl ports.
perl uses @INC to figure out where your perl modes are, you can
check with:
perl -e 'print join "\n", @INC'
With MacPorts you will need to use the /opt/local path to perl
So, for reasons I am not entirely sure of, some perl mods will look
at the macports @INC, and some will look at the default @INC. How
do we solve this? Why do some perl mods look in the default, is
this something I should take to the developers of the perl mods?
There seems to be two ways to solve this:
1. Add the directory to the PERL5LIB environment variable.
2. Add use lib 'directory'; in your Perl script.
I think the first way is simplest, but not so portable. I am not
even sure a port file can modify .profile or .bashrc, and even
then, from what my experience is, env vars are a gotcha moment with
MacPorts. It certainly lives outside of /opt/local so to me, less
than idea.
The second way may be best, but I have to work with the developer
of ASSP to figure out where to best add this in.
Any suggestions?
On Jan 21, 2009, at 7:56 PM, Frank J. R. Hanstick wrote:
Hello,
The problem I had with two gcc's was that one call to the gcc was
done direct (gcc) instead of an indirect prefix variable
[ ($SRC)gcc ]. I would look into ASSP to be sure that all calls
to perl modules use the indirect method. There may be some
elements where the call is direct (using the pathname) rather than
using the indirect "I told you where to look". If the three
offending calls use the direct method, then those need to be
changed to indirect. The behavior you describe points to what I
have seen. I may be wrong; but, it is a place to start.
Frank
--
Scott
--
Scott
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users