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

Explore LLVM markers in dylibs re: compatibility with Xamarin Studio < 9.0 and cordova apps #300

Open
jmoody opened this issue Dec 1, 2015 · 8 comments
Assignees

Comments

@jmoody
Copy link
Contributor

jmoody commented Dec 1, 2015

Experiment

  1. Generate FAT dylib without bitcode enable; check for LLVM markers (see build scripts)
  2. Does this dylib work with:
    • a. Xamarin Studio < 9.0
    • b. Cordova apps.
@jmoody jmoody added the task label Dec 1, 2015
@jmoody jmoody self-assigned this Dec 1, 2015
@jmoody jmoody assigned sapieneptus and unassigned jmoody Dec 21, 2015
@jmoody
Copy link
Contributor Author

jmoody commented Dec 21, 2015

@sapieneptus

I generated a FAT dylib with no bitcode markers.

@sapieneptus
Copy link

I wonder if we couldn't get a dedicated device host in XTC with a few iOS devices just for being able to do some kind of CI with physical devices (for things of the not-to-be-named variety that must be tested on physical devices). @krukow

@jmoody jmoody added the epic! label Dec 21, 2015
@krukow
Copy link
Contributor

krukow commented Dec 21, 2015

@sapieneptus what's wrong with using the normal XTC interface?

@sapieneptus
Copy link

@krukow I was thinking about finding a way to smoke test things like building/deploying to device, testing different dylibs against physical devices (to test library architecture compatibility) etc... not so much running actual automation tests.

We could write a bunch of service containers / pipelines to handle this, but for our CI needs I think it's overkill. Point being, XTC already has some device lifecycle management that I don't think we could get from, say, a hosted Jenkins or something, so if we could just get that functionality on a device host and be able to ssh in and run jobs, that would be nice.

Might be an over simplification, but there is a lingering difficulty in smoke testing certain types of physical-device interactions effectively.

@jmoody
Copy link
Contributor Author

jmoody commented Dec 22, 2015

A step in the right direction would be options for selecting devices from the command line.

@sapieneptus
Copy link

To play devil's advocate on that one, you can use the XTC API to get device selection, then use regex or something to find the one you want (say via ruby script).

But I still think it's a bit overkill to go through a whole XTC test run when we'd really just be testing, say, that a dylib is compatible with a given app for a physical device. I guess we'll take this offline, but alternatively @jmoody we could do a CI on a mac-mini that someone physically owns. We'd just need to do some error handling for when the thing is off / not available.

@jmoody
Copy link
Contributor Author

jmoody commented Jan 4, 2016

you can use the XTC API to get device selection

I have never seen this. Can you demonstrate?

we could do a CI on a mac-mini that someone physically owns.

This is the kind of thing that I usually do locally. I have most of the iPhone/iPad and iOS versions combinations. I have thought about setting up Jenkins on my network. Let's discuss off line.

@jmoody
Copy link
Contributor Author

jmoody commented May 27, 2016

@kasperlanger ^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants