[94304] trunk/dports/kde/kdevplatform

[Ryan Schmidt]

On Jun 14, 2012, at 11:09, nicos at macports.org wrote:

> Revision: 94304
>          https://trac.macports.org/changeset/94304
> Author:   nicos at macports.org
> Date:     2012-06-14 09:09:56 -0700 (Thu, 14 Jun 2012)
> Log Message:
> -----------
> kdevplatform: enabling clang also on 10.6 (ticket #34859)
> 
> Modified Paths:
> --------------
>    trunk/dports/kde/kdevplatform/Portfile
> 
> Added Paths:
> -----------
>    trunk/dports/kde/kdevplatform/files/
>    trunk/dports/kde/kdevplatform/files/patch-modificationrevision.diff
> 
> Modified: trunk/dports/kde/kdevplatform/Portfile
> ===================================================================
> --- trunk/dports/kde/kdevplatform/Portfile	2012-06-14 15:50:03 UTC (rev 94303)
> +++ trunk/dports/kde/kdevplatform/Portfile	2012-06-14 16:09:56 UTC (rev 94304)
> @@ -33,8 +33,17 @@
> depends_lib-append  port:kdelibs4 \
>                     port:boost
> 
> +platform darwin 10 {
> +    #Adjusting flags for clang on SL and 
> +    #patching <unordered_map> (ticket #34859)
> +    if {${configure.compiler} == "clang"} {
> +        patchfiles-append       patch-modificationrevision.diff
> +        configure.args-append   -DCMAKE_CXX_FLAGS="-Wno-reserved-user-defined-literal"
> +    }
> +}
> +
> #Adjusting configure flags for Clang on Lion (ticket #34545)
> -if {${configure.compiler} == "clang"} {
> +platform darwin 11 {
>     configure.args-append   -DCMAKE_CXX_FLAGS="-Wno-reserved-user-defined-literal -stdlib=libc++"
> }

I don't have Xcode 4 yet to test this, but are you sure about this change, and the equivalent one in r94305 for kdevelop? I'm not convinced it's correct to select the patches based on the OS version; rather I would have expected this to depend on the compiler and possibly the compiler version (or Xcode version). Prior to this change, you were making changes when the compiler is clang; this seemed reasonable. As it's written now, your Snow Leopard code will execute for clang only, which is probably what you intended, whereas your Lion code will execute for either clang or llvm-gcc-4.2, depending on the Xcode version, and you may not have intended that. Furthermore, now nothing will execute on the upcoming Mountain Lion (where we'll also be using clang) and you may not have meant to make that change either.

It might be useful to know, for each of the changes you make, what is it for:

both ports:
* -Wno-reserved-user-defined-literal? Is this needed to fix a clang build warning or error? If so this should be based on ${configure.compiler} == "clang"
* -stdlib=libc++? I understand this is a new thing on Lion. Thus I would not expect Apple to remove it in the upcoming Mountain Lion. So you should probably add that on Lion *and up*, not just on Lion, by checking ${os.major} >= 11

kdevplatform:
* patch-modificationrevision.diff? Is this to remove the parts that would otherwise depend on -stdlib=libc++? If so this could be the "else" part of the "if" statement that adds -stdlib=libc++

kdevelop:
* patch-parser.diff? Seems to be similar to kdevplatform's patch-modificationrevision.diff
* patch-context.diff, patch-declarationbuilder.diff?


> Added: trunk/dports/kde/kdevplatform/files/patch-modificationrevision.diff
> ===================================================================
> --- trunk/dports/kde/kdevplatform/files/patch-modificationrevision.diff	                        (rev 0)
> +++ trunk/dports/kde/kdevplatform/files/patch-modificationrevision.diff	2012-06-14 16:09:56 UTC (rev 94304)
> @@ -0,0 +1,31 @@
> +--- language/editor/modificationrevision.cpp.orig	2012-04-14 04:49:31.000000000 +0900
> ++++ language/editor/modificationrevision.cpp	2012-06-08 10:40:54.000000000 +0900
> +@@ -26,19 +26,20 @@
> + #if defined(Q_CC_MSVC)
> + #include <hash_map>
> + using namespace stdext;
> +-#elif defined GXX_LT_4_3
> ++//#elif defined GXX_LT_4_3
> ++#else
> + #include <ext/hash_map>
> + using namespace __gnu_cxx;
> +-#else // C++0X
> ++//#else // C++0X
> + // TODO: Replace hash_map with unordered map when support for G++ < 4.3 has 
> + //       ended. This class was added as a temporary workaround, to get rid of
> + //       hash_map related warnings for g++ >= 4.3.
> +-#include <unordered_map>
> +-template<class _Key, class _Tp,
> +-       class _Hash = std::hash<_Key>,
> +-       class _Pred = std::equal_to<_Key>,
> +-       class _Alloc = std::allocator<std::pair<const _Key, _Tp> > >
> +-class  hash_map : public std::unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc> { };
> ++//#include <unordered_map>
> ++//template<class _Key, class _Tp,
> ++//       class _Hash = std::hash<_Key>,
> ++//       class _Pred = std::equal_to<_Key>,
> ++//       class _Alloc = std::allocator<std::pair<const _Key, _Tp> > >
> ++//class  hash_map : public std::unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc> { };
> + #endif