iossim: ERROR: Invalid SDK version: 8.1
Supported device/SDK combinations:
-d 'iPhone 4s' -s '8.3'
-d 'iPhone 5' -s '8.3'
-d 'iPhone 5s' -s '8.3'
-d 'iPhone 6 Plus' -s '8.3'
-d 'iPhone 6' -s '8.3'
-d 'iPad 2' -s '8.3'
-d 'iPad Retina' -s '8.3'
-d 'iPad Air' -s '8.3'
-d 'Resizable iPhone' -s '8.3'
-d 'Resizable iPad' -s '8.3'
ERROR: Non-zero return code '3' from command: Process exited with status 3.
ERROR: Loading of target '//tools/objc:default_provisioning_profile' failed; build aborted: no such target '//tools/objc:default_provisioning_profile': target 'default_provisioning_profile' not declared in package 'tools/objc' defined by /Users/indigoorton/Documents/Github/Master/Master/tools/objc/BUILD.
ERROR: Loading failed; build aborted.
build --ios_sdk_version=8.3 --cxxopt "-std=c++11" --linkopt "libc++" --conlyopt "-std=gnu99"
run --ios_sdk_version=8.3 --cxxopt "-std=c++11" --linkopt "libc++" --conlyopt "-std=gnu99"
Hi David,That's exactly what is happening to me. Thanks for the solution!I have a lot of objc_libraries that compile most of my code (I'm writing an API), then I use an objc_binary for my app (testing app) sources and an ios_application for all app specific resources (e.g. info.plist, bundle id).Have you found a way of running the app on a device? Or do you just build the application and then install the .ipa manually through xcode/itunes?
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/8133649a-6a20-424a-8b5b-30a487e48145%40googlegroups.com.--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To post to this group, send email to bazel-...@googlegroups.com.
Sorry, we're a bit overloaded with ios requests right now. There are still some pieces missing from bazel, in particular test support (which will hopefully also support running the test on a device).From memory, I think we're building an ipk; can that be uploaded to a device?Wrt. xcode project generation, can you be more specific as to what is missing?
On Tuesday, April 21, 2015 at 9:52:06 AM UTC-7, Ulf Adams wrote:Sorry, we're a bit overloaded with ios requests right now. There are still some pieces missing from bazel, in particular test support (which will hopefully also support running the test on a device).From memory, I think we're building an ipk; can that be uploaded to a device?Wrt. xcode project generation, can you be more specific as to what is missing?Sorry for any contribution to the overload, not intended! I noticed that this commit (https://github.com/google/bazel/commit/44d00bfb252abb32f8f0c17b642b47a0f99b06b1) appears to have resolved my ios_application() issue. It does now build and run successfully in Xcode, and I can run my app on my iOS devices using Xcode. I will look into the .ipa files and see if there is a way to make Xcode run the ones built by Bazel on the device. I've only ever run projects I build through Xcode.
But maybe nothing is missing from the xcodeproj generation. It depends on what the intended workflow is for using Bazel for iOS. Some essential aspects of Xcode seem difficult and unnecessary to replace, so it's a matter of where the lines are drawn between Bazel and Xcode. It could well be that the fix for our issues here is a few paragraph long blog post or documentation page about how to accomplish the key tasks in building an iOS app using Bazel. As it is now, I think it's easy for people to see an xcodeproj get spit out after a bazel build and think that the project should be buildable in Xcode, when it might be the case that this is not what was intended, and the xcodeproj is there for working with xibs and core data models and other things like that.
So that said, I posted (https://groups.google.com/forum/#!topic/bazel-dev/m4zdsR_PcEM), which reports that the xcodeproj generated for Bazel's example iOS application will fail to copy the compiled CoreData models into the application bundle when built via Xcode, causing a runtime failure at launch. The file runs correctly when built and run through Bazel. It appears that Bazel uses its own method of compiling/bundling the coredata models, and does not leave any build instructions for how to do that in the generated xcodeproj. Again, possibly working as intended, but could be confusing to users who attempt to build the example project through Xcode.
Along similar lines, I have a small worry about the plist files. Bazel appears to have its own tool to merge together plist files, so it does this during the bazel build and then generates an xcodeproj that points at the bazel-merged plist file. This is not a file the user can see in their source directory, but it does appear in Xcode as a "source" file, when really it's an output. Meanwhile the actual input plists don't appear in the Xcode project. Xcode will let them edit the merged file, which I imagine will work until they do a bazel rebuild and lose their changes. It seems like docs should mention this, at least. Perhaps someday bazel could generate custom rules in the xcodeproj to run the plist merge in the same way as it would on the command line, but that would be a lot more work, I imagine. The plist editing interface in Xcode is nice to use, though.
--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To post to this group, send email to bazel-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/4cd7f61f-988e-48cf-ae33-77506df4ddeb%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To post to this group, send email to bazel-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/4cd7f61f-988e-48cf-ae33-77506df4ddeb%40googlegroups.com.
So that said, I posted (https://groups.google.com/forum/#!topic/bazel-dev/m4zdsR_PcEM), which reports that the xcodeproj generated for Bazel's example iOS application will fail to copy the compiled CoreData models into the application bundle when built via Xcode, causing a runtime failure at launch. The file runs correctly when built and run through Bazel. It appears that Bazel uses its own method of compiling/bundling the coredata models, and does not leave any build instructions for how to do that in the generated xcodeproj. Again, possibly working as intended, but could be confusing to users who attempt to build the example project through Xcode.I'm pretty sure that's not WAI.
Along similar lines, I have a small worry about the plist files. Bazel appears to have its own tool to merge together plist files, so it does this during the bazel build and then generates an xcodeproj that points at the bazel-merged plist file. This is not a file the user can see in their source directory, but it does appear in Xcode as a "source" file, when really it's an output. Meanwhile the actual input plists don't appear in the Xcode project. Xcode will let them edit the merged file, which I imagine will work until they do a bazel rebuild and lose their changes. It seems like docs should mention this, at least. Perhaps someday bazel could generate custom rules in the xcodeproj to run the plist merge in the same way as it would on the command line, but that would be a lot more work, I imagine. The plist editing interface in Xcode is nice to use, though.We chmod all output files read-only (I think). If you work with bazel a lot, you quickly learn that files under bazel-out aren't intended for editing. But I guess we could be more explicit about that in the docs.
Hi David,thanks a lot for your thoughtful feedback! The eventual goal is definitely for the Bazel-generated Xcode projects to be buildable, anything else is a bug. With the introduction of ios_application (which happened very recently) we've fallen behind a bit and its support in particular for the project generation is broken in several places. We're slowly addressing that and any assistance is welcome! :)With regards to custom tools employed by blaze during its build of an IPA for steps normally performed by Xcode, those should reflect the same work done by Xcode. In most cases (e.g. actool or ibtool) we call a thin wrapper around an existing tool that is also called by Xcode.The plist is an interesting and tricky case, but I agree that eventually the individual pieces should be editable in the project, not the merged one. The reason why the merged one may be necessary right now is that Blaze performs some variable substitutions on it which would need to be replicated as a custom step in Xcode.Oh, and that the example project doesn't build in Xcode is a bug, we'll have to look into that. It should work (and I thought I'd seen it work) so not sure what's going wrong.
David, have you run into a bundling error when running in a simulator? I have my Main.storyboard included in the objc_binary (note: I have fallen back to using that, as you said), however, when I run the app it breaks saying "Could not find a storyboard named 'Main' in bundle NSBundle".
--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To post to this group, send email to bazel-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/9ae43cb6-a4e3-4568-a224-56a68c7281b6%40googlegroups.com.
Thanks for looking further into this! A fix would be much appreciated.
It is unfortunate that ibtoolzip hardcodes the --compile flag. I'd like to avoid adding another tool though, maybe we can pass a new parameter that indicates whether to compile from a file or directory?
Families are a little trickier, they're currently defined on release bundles only, whereas storyboards can be defined anywhere and are compiled as part of any bundle. Since it's possible to build a bundle directly (using Blaze), we can't rely on the information coming from the app or extension and so need to move the families attribute to bundles in general. Then we should be able to easily pass it to the ibtool invocation.