On Jun 14, 2012, at 11:09, [email protected] wrote:
> Revision: 94304
> https://trac.macports.org/changeset/94304
> Author: [email protected]
> 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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
