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

Library Does Not Support Installation Via Swift Package Manager #1387

Closed
joeljfischer opened this issue Aug 27, 2019 · 6 comments
Closed

Library Does Not Support Installation Via Swift Package Manager #1387

joeljfischer opened this issue Aug 27, 2019 · 6 comments
Assignees
Labels
best practice Not a defect but something that should be improved anyway distribution Relating to distribution of the library to developers

Comments

@joeljfischer
Copy link
Contributor

Bug Report

Currently, the library does not support installation via Swift Package Manager due to SPM's inability to resolve submodules see here for more info. We will have to move the submodule code into the library.

Reproduction Steps
  1. Set up Xcode 11 with a sample app
  2. Attempt to install sdl_ios via SPM
Expected Behavior

The imported package works correctly

Observed Behavior

The imported package fails to work correctly due to failures around the BSON lib.

OS & Version Information
  • iOS Version: n/a
  • SDL iOS Version: 6.4-develop
  • Testing Against: Xcode 11
@joeljfischer joeljfischer added bug A defect in the library distribution Relating to distribution of the library to developers labels Aug 27, 2019
@joeljfischer joeljfischer added this to the 6.4.0 milestone Aug 27, 2019
@joeljfischer joeljfischer self-assigned this Aug 27, 2019
@thedavidharris
Copy link

thedavidharris commented Jul 16, 2020

I've got a working POC of this at https://github.com/thedavidharris/sdl_ios/tree/spm-support just adding some modulemaps to build bson in place with some symlinks, but there are a few caveats:

  • SPM needs a public headers path, not them to be individually specificied as is. I can move all of these to /include, but it gets messy. Ideally, I think the whole folder structure of the project needs to be adjusted, as the current xcodeproj file is working off of folder references and any adjustments to support things like SPM would be a fair bit of work.
  • In order to get around this, all the headers are public right now.
  • There's an empty .swift file in the test target that needs to get removed, Swift and Objective-C can't be mixed in the same target.
  • Doesn't add the Resource files or Localization yet

If you want @joeljfischer I can continue plugging away at some of these, but that folder structure problem I didn't want to work out without consulting the team.

@joeljfischer
Copy link
Contributor Author

Hi @thedavidharris, thanks for looking into this more. There's been an open issue for a long time to move the project to have public and private files in separate folders. That does eventually need to happen, we just keep putting it off. I think it would be a necessary part of having official SPM support.

There's an empty .swift file in the test target that needs to get removed, Swift and Objective-C can't be mixed in the same target.

This seems to be a legacy file from when the quick testing library needed it. I deleted it locally and ran the tests and they seemed to work fine now. That could be removed.

Doesn't add the Resource files or Localization yet

These are necessary because without them the lock screen won't work. I know that support for that is coming in Xcode 12, but I haven't looked deeper into it.

@thedavidharris
Copy link

All that sounds good. I'd agree that addressing #568 is a pre-requisite. After that, this should be able to flow through and still export the packages correctly, with the resources once Xcode 12 comes, so gives a little time.

What would be the ideal folder structure for the project? Something that mirrors the virtual folders in Xcode today but one layer deeper in public/private?

@joeljfischer
Copy link
Contributor Author

I think that the folder structure would just be public and private, not mirroring the Xcode virtual folder structure. I worry that with additional public / private below the virtual structure it would get too messy and difficult to maintain.

@joeljfischer
Copy link
Contributor Author

@thedavidharris Hello, #568 has been fixed and closed. Did you want to submit a PR for this? If so, there's a deadline of it being merged on 09/18, so we would need the PR submitted by 09/11, and you would need to be responsive to the PR review to get it done by our release deadline.

Otherwise, I can take it on and fix it. If I do, do you mind if I re-use the work you did on that branch?

@thedavidharris
Copy link

Hey @joeljfischer , apologies been out for a few weeks. Likely won't get a chance to pick this up myself the next couple weeks (and our teams don't need any SPM support in the near-term), so if you're up for it definitely good to re-use some of this work.

@joeljfischer joeljfischer added best practice Not a defect but something that should be improved anyway and removed bug A defect in the library labels Sep 17, 2020
@NicoleYarroch NicoleYarroch removed this from the 6.4.0 milestone Oct 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
best practice Not a defect but something that should be improved anyway distribution Relating to distribution of the library to developers
Projects
None yet
Development

No branches or pull requests

3 participants