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
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
