scope of "local" PortGroup definition files

[Ryan Schmidt]

On Jan 9, 2015, at 6:23 AM, René J.V. Bertin wrote:
> 
> On Friday January 09 2015 12:18:16 Rainer Müller wrote:
> 
>>> Is that correct and if so, is there a way to override the definitions
>>> on a global basis?
>> 
>> Port groups not found in the current ports tree are being looked up in
>> the ports tree marked with [default] in sources.conf.
> 
> That's not what I'm seeing. What I'm seeing, at least not with the compiler-blacklist port group on linux. I've changed my "local" copy to skip the version parsing (= return early) when `uname` doesn't return Darwin, instead of raising an error because Linux clang -v output doesn't correspond to the expected format. This works for my own ports in that local repo, but ports in the default tree continue to raise the error unless I apply the same change in the default PortGroup definition.
> 
> NB: my only reason to "use" MacPorts on Linux is to be able to do some minimum portfile development/maintenance from there, without having to log in to OS X.
> NB2: my mod uses uname because for some reason ${os.platform} is not available from the version parsing procedure.

I've committed this fix to the portgroup in r131321.

Note that you need to "global" options (like os.platform) to use them in a proc.

I am not surprised that portgroups not in the default dports tree are not being honored; I was experiencing the same issue 8 months ago or so. I thought it got fixed, but maybe not, or maybe it only got fixed on trunk and we haven't released a new version of base yet.