This repository has been archived by the owner on Feb 2, 2021. It is now read-only.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This doesn't yet build the mobile-installation-helper.app, but that's next.
Can Buck support the concept of host/target platforms, so you can avoid some of the genrule()'s and hardcoding #macosx-x86_64? Can you avoid the lipo genrules and assume that when that support is needed, Buck will handle fat binaries natively? |
These are all awesome questions. Since Buck was written and designed to build Java, it doesn't have the concept of host/target platforms yet. I've been thinking about how to integrate those. |
🎉 |
bhamiltoncx
added a commit
that referenced
this pull request
May 29, 2015
Allow xctool to build with Buck
sdwilsh
pushed a commit
to facebook/buck
that referenced
this pull request
Jun 3, 2015
Summary: Currently, Buck `apple_test` rules use the open-source `xctool` utility, which either has to exist in the repository as a compiled binary, or called via a wrapper script which uses Xcode to build the utility. Building `xctool` with Xcode takes about 45 seconds and gives no visible output to the user. @k21 mentioned it'd make more sense to build xctool from source, and I agree. As an alternative, this builds on this pull request I sent in: facebookarchive/xctool#518 to allow building xctool from source with Buck itself. This will allow us to cache it in the HTTP cache, etc. Because `xctool` is sensitive to the layout of its files, we have to invoke a `genrule` which lays out the binary, its supporting utilities, and supporting libraries in the correct directory structure, then zips the result. We unzip it before running the tests. Test Plan: Updated `xctool` to commit 2978953f5b3dff49da0e57ad60497054f9023072 in Apple repo. Added to `.buckconfig.local`: [apple] xctool_zip_dep = //path/to:xctool-zip Ran `buck test //path/to:apple_test`, confirmed it built xctool and ran test successfully. If we like this approach, I can deprecate the support for running `xctool` directly and remove the copy of the binary we have checked in to the `test` directory.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This doesn't yet build the mobile-installation-helper.app, but that's next.
I'm thinking about how we might want to run xctool tests via Buck. Maybe directly with
xctest
?I tested this with:
I also ran the compiled
xctool
by hand to run a few tests for iOS, it worked fine.