ASSP port testing, not getting all perl mods to work
Frank J. R. Hanstick
trog24 at comcast.net
Thu Jan 22 20:51:20 PST 2009
Hello,
Which is a little too deep for me. I am only indicating anomalies
from expected behavior and possible causes. My guess would be ASSP
since it is looking for the modules. There might be a difference in
the reference formation. The alternative is to wait for someone else
to fix the problem.
Frank
On Jan 22, 2009, at 8:23 PM, Scott Haneda wrote:
> 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
>
More information about the macports-users
mailing list