[lldb-dev] lldb/test/expression_command/persist_objc_pointeetype/main.m depends on CloudKit.h

Enrico Granata egranata at apple.com
Tue May 12 13:57:31 PDT 2015


I think I see… on my machine CloudKit is in PrivateFrameworks

If you replace the #import with an @class CKDatabase; forward-declaration does anything improve?

Failing even that, I will need to change this test to use a more publicly available class

> On May 12, 2015, at 1:51 PM, Vince Harron <vince at nethacker.com> wrote:
> 
> Note that the 6.1.1 mac's clang *does* include
> 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks
> 
> (It gets past the include failure)
> 
> 
> On Tue, May 12, 2015 at 1:48 PM, Vince Harron <vince at nethacker.com <mailto:vince at nethacker.com>> wrote:
> I've done a little investigating on this.
> 
> On my MacPro (Xcode 6.2), the inferior binary fails to build because it can't find a header file.
> 
> os command: make MAKE_DSYM=NO ARCH=x86_64 CC="clang" 
> with pid: 14574
> stdout: clang -g -O0 -arch x86_64   -I/Users/vharron/ll/tot/lldb/test/make/../../include -include /Users/vharron/ll/tot/lldb/test/make/test_common.h   -c -o main.o main.m
> 
> stderr: main.m:6:9: fatal error: 'CloudKit/CloudKit.h' file not found
> #import <CloudKit/CloudKit.h>
>         ^
> 1 error generated.
> main.m:6:9: fatal error: 'CloudKit/CloudKit.h' file not found
> #import <CloudKit/CloudKit.h>
>         ^
> 1 error generated.
> make: *** [main.o] Error 1
> 
> vharron-macpro3:test vharron$ find / -name CloudKit.framework 2>/dev/null
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/CloudKit.framework
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks/CloudKit.framework
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/CloudKit.framework
> 
> That mac's clang -v reports:
> 
> vharron-macpro3:test vharron$ cat main.cpp
> int main() {return 0;}
> vharron-macpro3:test vharron$ clang -v main.cpp
> Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
> [snip]
> clang -cc1 version 6.0 based upon LLVM 3.5svn default target x86_64-apple-darwin13.4.0
> ignoring nonexistent directory "/usr/include/c++/v1"
> ignoring nonexistent directory "/usr/local/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
>  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include
>  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
>  /usr/include
>  /System/Library/Frameworks (framework directory)
>  /Library/Frameworks (framework directory)
> End of search list.
> [snip]
> 
> Notice that 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks
> Is not in the list.
> 
> I think that upgrading to Xcode 6.2 is what made clang lose this path.
> 
> On a XCode 6.1.1 mac, we have the path, but we get a different compile error (I'll send that to you when I can reproduce it.):
> 
> [snip]
> clang -cc1 version 6.0 based upon LLVM 3.5svn default target x86_64-apple-darwin13.4.0
> ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/v1"
> ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/local/include"
> ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/Library/Frameworks"
> #include "..." search starts here:
> #include <...> search starts here:
>  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
>  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include
>  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
>  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include
>  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks (framework directory)
> End of search list.
> [snip]
> 
> 
> On Tue, May 12, 2015 at 10:56 AM, Enrico Granata <egranata at apple.com <mailto:egranata at apple.com>> wrote:
> 
>> On May 10, 2015, at 12:21 AM, Vince Harron <vharron at google.com <mailto:vharron at google.com>> wrote:
>> 
>> Should the dependency be removed or require CloudKit to run the tests?
>> 
>> -- 
>> 
>> Vince Harron |	 Technical Lead Manager |	 vharron at google.com <mailto:vharron at google.com> |	 858-442-0868 <tel:858-442-0868>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu <mailto:lldb-dev at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev>
> 
> Is there a specific issue with the CloudKit framework?
> 
> Thanks,
> - Enrico
> 📩 egranata@.com <emoji_u260e.png>️ 27683
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu <mailto:lldb-dev at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev>
> 
> 
> 


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150512/ac54341f/attachment.html>


More information about the lldb-dev mailing list