-
Notifications
You must be signed in to change notification settings - Fork 344
[CAS] gmodule support for caching build #11026
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: next
Are you sure you want to change the base?
Conversation
2bbc405
to
075be6d
Compare
075be6d
to
2a1ffca
Compare
2a1ffca
to
d5d9a15
Compare
@@ -0,0 +1,58 @@ | |||
#!/usr/bin/env python3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would potentially fit better into llvm-project/lldb/packages/Python/lldbsuite/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a compiler launcher type of script and requires a just built clang (because it needs clang-scan-deps next to it). I don't what is a good way to hack into lldbsuite or driven from makefile. Let me know if you have any good idea.
When using include-tree, all the relative paths references should be turned into absolute path already. There is no need to pass options like `-fdebug-compilation-dir` for debug info generation as it makes cache hit less likely when two identical compilations where performed with different compilation directories.
Fix the unittest build when swift support is off.
d5d9a15
to
0173e49
Compare
Prototype for gmodule support by switching
splitDwarf
references to CASIDs of the module/PCHAlso teach dsymutil to support reading from CAS as a prototype for lldb support.