ASSP port testing, not getting all perl mods to work

[Scott Haneda]

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