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

Add macOS Xcode archive support #5862

Merged
merged 17 commits into from Apr 15, 2019

Conversation

@wjk
Copy link
Contributor

wjk commented Apr 7, 2019

Does mostly what the title says. Note that this code is totally untested (mostly due to how hard it is to do an end-to-end build of Xamarin.Mac; I have tried and failed several times in the past). I am mainly opening the PR now both for feedback, and so the CI bot can tell me what I did wrong. Note also the TODO comments in my added code; I would appreciate some guidance on how to deal with those. Thanks so much!

@rolfbjarne

This comment has been minimized.

Copy link
Member

rolfbjarne commented Apr 8, 2019

build

@monojenkins

This comment has been minimized.

Copy link
Collaborator

monojenkins commented Apr 8, 2019

Build success
Build succeeded
API Diff (from stable)
API Diff (from PR only) (no change)
Generator Diff (no change)
Test run succeeded

@chamons

This comment has been minimized.

Copy link
Member

chamons commented Apr 8, 2019

👋 Thanks for the contribution!

I think the biggest thing this is missing is a test. I don't personally know archive well enough to know if this works \ continues working. Maybe we can write a test like this one? Generate a project, run the archive target, and compare the output to expected files.

Would that be something you'd be up for trying @wjk ?

@jstedfast - Could you review the task parts?

@chamons chamons self-assigned this Apr 8, 2019

@wjk

This comment has been minimized.

Copy link
Contributor Author

wjk commented Apr 8, 2019

@chamons I can certainly try, but the main way of testing if an Xcode archive is valid is to import it into Xcode and see if it complains, and that can only be done by hand.

Doing this may take me a while, though, due to how hard it is for me to build Xamarin.Mac. (My university has set up their internet service to momentarily interrupt the connections of users who download more than X bytes in Y period of time to "deter illegal file sharing" — which, by the way, is a nonsense excuse. As such, if I try to recursively clone the xamarin-macios repo, my connection gets hiccuped and Git crashes; I must then retry the download from the beginning, only for my connection to hiccup again…) Thanks for bearing with!

@chamons

This comment has been minimized.

Copy link
Member

chamons commented Apr 8, 2019

@wjk You could look into trickle or other bandwidth shaping tools. They let you invoke a command and set a bandwidth "cap", which might allow you to more easily stay within your universities constraints. I've never personally used it, however.

Please let me know if you think you'll be unable to continue on this, I'm happy to pick some some of the work if necessary to make sure we can land it.

Thanks again!

@wjk

This comment has been minimized.

Copy link
Contributor Author

wjk commented Apr 8, 2019

@jstedfast The ArchiveTaskBase class in Xamarin.MacDev.Tasks.Core has marked its ITunesSourceFiles parameter as [Required], yet this parameter is meaningless on macOS AFAICT. As such, this will cause errors when attempting to create a macOS archive. Should I just get rid of the [Required] attribute?

@jstedfast

This comment has been minimized.

Copy link
Contributor

jstedfast commented Apr 8, 2019

I think the better approach would be to move that property & attribute over to the Xamarin.iOS.Tasks.Core.ArchiveTaskBase class.

@wjk

This comment has been minimized.

Copy link
Contributor Author

wjk commented Apr 8, 2019

@chamons Would it be possible for you to test this as you offered above? Download cap or no download cap, building Xamarin.Mac is still way too much of a pain for me; I managed to get reset-submodules to succeed, but then ran into problems with provisioning. (I really don't like having multiple versions of Xcode around; it tends to confuse Launchpad.) If you could take over this task I'd be very appreciative. Thanks!

(Also: That trickle program you linked doesn't throttle bandwidth; it is purely an amusement that rate-limits the passage of characters to the terminal.)

@dalexsoto dalexsoto added the community label Apr 8, 2019

@chamons

This comment has been minimized.

Copy link
Member

chamons commented Apr 8, 2019

That's unfortunate about trickle, that would have been useful. What I get for suggesting without detail reading.

I'll take a look at this later this week.

arInfo.Add ("SolutionPath", new PString (SolutionPath));
}

if (!string.IsNullOrEmpty (InsightsApiKey))

This comment has been minimized.

Copy link
@chamons

chamons Apr 8, 2019

Member

@wjk is this an Apple thing or something else? Who's key is it?

This comment has been minimized.

Copy link
@wjk

wjk Apr 8, 2019

Author Contributor

I simply copied it from the iOS version. The targets file implies it's the Xamarin Insights API key. I don't think it's used anywhere, honestly.

arInfo.Add ("Name", new PString (plist.GetCFBundleName () ?? plist.GetCFBundleDisplayName ()));
arInfo.Add ("ApplicationProperties", props);

if (!string.IsNullOrEmpty (ProjectGuid))

This comment has been minimized.

Copy link
@chamons

chamons Apr 8, 2019

Member

Were these just things you found useful or needed for archive?

This comment has been minimized.

Copy link
@wjk

wjk Apr 8, 2019

Author Contributor

@jstedfast requested I add it.

This comment has been minimized.

Copy link
@jstedfast

jstedfast Apr 9, 2019

Contributor

They are for the IDE to associate projects/solutions with the archive

This comment has been minimized.

Copy link
@chamons

chamons Apr 9, 2019

Member

👍 thanks everyone!

@chamons

This comment has been minimized.

Copy link
Member

chamons commented Apr 11, 2019

I've hacked on it enough that a build with /p:ArchiveOnBuild=true does not error and generates an xcarchive.

However, they aren't loadable by Xcode.

@wjk - Were you able to load load generated xcarchive in Xcode using your generated bundles?

@wjk

This comment has been minimized.

Copy link
Contributor Author

wjk commented Apr 11, 2019

@chamons I’ve found the cause of the problem, but I don't know how to solve it. The issue is that the plist-writing framework is using an invalid <date> format in the XML plist, as follows:

<!-- This was written natively by Xcode. -->
<key>CreationDate</key>
<date>2019-04-07T00:29:58Z</date>

<!-- This was written by VSMac. -->
<key>CreationDate</key>
<date>2019-04-11T18:02:00-04:00</date>

This appears to be a bug in PlistObject. I suspect that the date needs to be converted to UTC before being written out, but I’ve tried calling DateTime.ToUniversalTime(); it doesn’t help. I’ve also tried wrapping the date in new PDate(...) explicitly; it doesn’t help either. Any pointers? Thanks!

@chamons

This comment has been minimized.

Copy link
Member

chamons commented Apr 12, 2019

That appears to be it.
Screen Shot 2019-04-12 at 11 02 49 AM

Works for both full and modern.

@chamons chamons requested a review from jstedfast Apr 12, 2019

@rolfbjarne

This comment has been minimized.

Copy link
Member

rolfbjarne commented Apr 12, 2019

build

@monojenkins

This comment has been minimized.

Copy link
Collaborator

monojenkins commented Apr 12, 2019

Build success
Build succeeded
API Diff (from stable)
API Diff (from PR only) (no change)
Generator Diff (no change)
Test run succeeded

@chamons chamons merged commit dc8e07f into xamarin:master Apr 15, 2019

2 checks passed

Build Build success. No test results found.
Details
license/cla All CLA requirements met.
Details
@chamons

This comment has been minimized.

Copy link
Member

chamons commented Apr 15, 2019

@wjk Thanks for the contribution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.