ASSP port testing, not getting all perl mods to work

Frank J. R. Hanstick trog24 at comcast.net
Thu Jan 22 19:29:33 PST 2009


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
>



More information about the macports-users mailing list