This is needed to build the test binaries for iOS. This is part of upstreaming the last missing pieces to run the on-device test suite with the upstream repository.
Details
- Reviewers
jasonmolenda davide friss labath - Group Reviewers
Restricted Project - Commits
- rGe5d08fcbac72: [lldb] Extend Darwin builder to pass the ARCH_CFLAGS spec to Make.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldbremote.py looks awfully Apple-specific, yet it is going to be called from the generic code. Is that not an issue?
It's not an issue because it checks for the Apple SDK, but I could hoist that out of the helper to make it more obvious.
- Simplify things a bit more
- Add a comment explaining that the triple spec is only relevant with an Apple SDK
The part which bugs me about this is that the first thing that Makefile.rules will do with the triple we've painstakingly constructed here is it will decompose it into individual components, and then do some more matching on them, including running some xcrun commands, which are already being run here. I do think that doing this in python is a good idea (I believe the main reason a lot of this stuff is done in make is so that running "make" would just work, but we are way past that point now), but if we're going to do that in python, how about we move all of that to python? It seems the only effect of the TRIPLE argument is to add -target $(TRIPLE) -m$(OS)-version-min=$(VERSION) to CFLAGS. That should be easy to achieve using the information that construct_triple has available.
How about making an abstract/dummy getTripleSpec (or whatever) method in the base builder class. Then the darwin builder could override it do to its thing, and all of this code could reside in builder_darwin.py. If any other platform decides it needs to set the triple argument, then it's likely it will do that via some completely different method.
lldb/packages/Python/lldbsuite/test/lldbremote.py | ||
---|---|---|
37–39 ↗ | (On Diff #284010) | when dealing with triples, I believe this field is usually called the "os", not "platform". |
Sounds reasonable.
How about making an abstract/dummy getTripleSpec (or whatever) method in the base builder class. Then the darwin builder could override it do to its thing, and all of this code could reside in builder_darwin.py. If any other platform decides it needs to set the triple argument, then it's likely it will do that via some completely different method.
Even though this file is called "base", there's no inheritance going on here, it's just methods and lldbtest.py will import the appropriate module. I considered this too, but didn't feel like rewriting those files as a classes for this small change. But if we're going to pass the TRIPLE, OS and VERSION separately, we might as well.
I'd just send the final ARCH_CFLAGS value. Then the Android.rules makefile could be ported to python as well.
This looks good to me, getting any logic out of the Makefile templates that we can, that's a good improvement for maintainability.
lldb/packages/Python/lldbsuite/builders/builder.py | ||
---|---|---|
201–202 ↗ | (On Diff #286455) | Instead of a new method for each variable any subclass might want to set it would probably be better to just have an getExtraMakeArgs method that each subclass can return whatever it wants. ARCH_CFLAGS is fairly generic, so it may make sense to keep that separate, but DSYMUTIL and CODESIGN (and maybe SDKROOT) sound like they could go into the "extra" category. |
It broke the Debian buildbot: http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/16095
And also Fedora (although there the commit looks as a different one): http://lab.llvm.org:8014/builders/lldb-x86_64-fedora?numbuilds=10000