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