Well, there may very well be issues in what I did, as quite some issues
occurred. I am also on SL with XCode 3.2, so that my testing possibilities are
limited, and the changes in the Portfile are the result of the reports listed
in the cited tickets.
Some changes are dependent on the OS, since as you pointed out, libc++ is new
on Lion and not available on SL. The patch forces to use older code available
in the original files avoiding this dependency.
To answer the detailed questions:
> 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"
It is an error, where the compiler specifically indicates that the default flag
leads to the error. I corrected and added checks every time for
${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
True. I corrected that.
>
> 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++
Exactly. Done.
> kdevelop:
> * patch-parser.diff? Seems to be similar to kdevplatform's
> patch-modificationrevision.diff
Exactly. I did the same correction as before.
> * patch-context.diff, patch-declarationbuilder.diff?
These patches are also platform-specific, as they solve clang errors which
occur when linking with libc++. They are thus not needed on SL.
Thanks for looking at that, I corrected it in r94443. Then, as you pointed out,
this still leaves llvm-gcc, for which I have no ways of testing/correcting it.
Cheers,
Nicolas
On Jun 18, 2012, at 6:54 PM, Ryan Schmidt wrote:
> 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
