[100683] trunk/dports/gis
Vincent Habchi
vince at macports.org
Thu Dec 27 05:41:57 PST 2012
Ryan,
On 25 déc. 2012, at 07:14, Ryan Schmidt <ryandesign at macports.org> wrote:
> You should use "compiler.blacklist" to blacklist compilers that don't work, instead of mandating a particular compiler:
>
> compiler.blacklist clang
>
> Especially, mandating llvm-gcc-4.2 will not work on versions of Xcode that do not provide llvm-gcc-4.2, such as Xcode 2.5.
That’s right. However, in this case, I found only one working compiler: llvm-gcc-4.2.
> Preferably, fix the port so that it compiles with clang. If you cannot, file a bug report with the developers, and put a link to that bug report in a comment in the portfile.
I can’t. The error is intricate, has probably to do with the code using GNU C++ extensions, and so forth. Besides, I’m not able to write or understand C++ beyond basic constructs, and this is going to be worse with the ongoing C++11 release.
Now, it seems that a 1.7 version is almost ready, and 2.0 should follow soon after. I’ll try to keep in touch with the upstream developers to find out if they intended to make the code clang compatible.
> IMO there is no need to blacklist macports-gcc-anything since there is no supported configuration of MacPorts that would have a macports-gcc compiler as the default compiler.
That’s true, but in the light of, e.g. Atlas performance figures, gcc4.7 is still far better than clang when it comes to scientific computing, let alone OpenMP capability. Clang has a long way here to catch up, beginning by auto-vectorizing which is more advanced in GCC, and leads to huge gains on some computations.
What would you advise?
>> +configure.pre_args -DCMAKE_INSTALL_PREFIX=${prefix}
>> +configure.args -DCMAKE_BUILD_TYPE=Release \
>> + -DCMAKE_INSTALL_NAME_DIR=${prefix}/lib
>
> You can remove these lines since the cmake portgroup already includes them.
Thanks for pointing this out. I’m going to commit a modification right away.
Vincent
More information about the macports-dev
mailing list