On Dec 8, 2012, at 21:14, Rainer Müller wrote:
> What should I specify in case I don't know yet when this will be fixed?
>
> Assume a port is broken with the current build of clang 421.11.66, but
> it is not clear in which build number this will be fixed or, if the
> developers say something like "fixed in next Xcode version", which build
> number of clang this will actually be.
>
> So I would have the options:
>
> a) Add {clang >= 421} to the blacklist
>
> This blacklist entry prevents any newer build of clang to be used.
This is what I would use.
> When
> eventually someone is brave enough to remove the blacklist entry we can
> probably not trace back which release of clang actually fixed the
> problem and might just add the most recent build number as upper bound.
If clang >= 421 fails to build the port, then the blacklist entry should not be
removed unless the source gets modified to work around the clang bug.
If a later version of clang e.g. 555 eventually does compile the port
correctly, then amend the blacklist with that information.
compiler.blacklist-append {clang >= 421 < 555}
> By the way it would be nice to have a shorter syntax for matching a
> specific major version as used in option b). Using {clang == 421} would
> be wrong as that only matches 421.0.0 exactly. Although I can't think of
> a good operator for this at the moment...
The portgroup doesn't parse the operators itself; it hands them to expr.
http://wiki.tcl.tk/583
We could change that if need be, but I have no knowledge of Apple's clang build
numbering strategy so specific numbers have no particular meaning to me. I
cannot guess at the meaning of an increase in any of the digits of the build
number. Therefore I recommend just specifying it as best you can and refine it
as further information becomes available.
The problem this portgroup was trying to solve is ports that indiscriminately
blacklist clang, when a particular problem is only caused by certain older
versions. This was happening frequently.
Less frequently we have the case you mention, where a newer version of clang
causes a problem. In this case we'll just have to test again with newer
versions of Apple clang and refine the blacklist when we find a newer version
that works again.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
