[103391] trunk/dports/aqua/qtiplot/Portfile

[Ryan Schmidt]

On Feb 28, 2013, at 08:44, Nicolas Pavillon wrote:

> On Feb 28, 2013, at 3:03 PM, Ryan Schmidt wrote:
> 
>> On Feb 27, 2013, at 22:03, Nicolas Pavillon wrote:
>>> On 28/02/2013 11:25, Ryan Schmidt wrote:
>>>> #Workaround as qtiplot build-phase hangs indefinitely on
>>>> -#Lion and higher (ticket #30761)
>>>> -if {${os.major} >= 11} {
>>>> +#Lion (ticket #30761)
>>>> +if {${os.major} == 11} {
>>>>   patchfiles-append   patch-disable-O2.diff
>>>> }
>>>> Are you sure this is based on the OS version? I'd expect it instead to be based on the version of clang, which in turn would be based on the version of the Xcode command line tools, but #30761 unfortunately did not record what versions of Xcode and clang people were using.
>>> You are probably totally right. I just changed for what I could test.
>>> However, if I followed correctly the work you did with compiler.blacklist (I did not have the occasion of testing it yet), this could be an ideal case to use it. I could just get rid of the limitation altogether, and blacklist the version(s) with problems when they are identified.
>> 
>> Yes, that might be easiest. I can test with Xcode 4.3.3, 4.5.2 and 4.6 and see if I can identify which versions of clang are problematic.
>> 
> Perfect. Did it in r103533. It should work with 4.6, as it is the version I could test.

I see the patchfile which the port was using until this change had this comment in it:

+# ticket #30761: qtiplot build-phase hangs indefinitely (compiling SymbolDialog.cpp)
+# bug reproduction: Mac OS X 10.7.2, Xcode 4.2.1, llvm-gcc-4.2 --version:
+#     i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
+# workaround: disable -O2 flag

I found it strange that it would mention Xcode 4.2.1 (with which the MacPorts default compiler is clang) but then list the version of llvm-gcc-4.2.

I then found that qtiplot doesn't respect the compiler choice, and filed this ticket:

https://trac.macports.org/ticket/38250

Once that's fixed, it'll be easier to figure out which compiler(s) qtiplot doesn't build with, so that they can be blacklisted in the qtiplot port.