[94304] trunk/dports/kde/kdevplatform

Tue Jun 19 07:16:12 PDT 2012

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, 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
> 
> 
> 