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.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
