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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Settings.app Acknowledgements.plist is missing? #79

Open
jerrymarino opened this issue Jun 14, 2017 · 5 comments
Open

Settings.app Acknowledgements.plist is missing? #79

jerrymarino opened this issue Jun 14, 2017 · 5 comments
Labels
P3 Would be nice, but probably next quarter at the earliest type: feature request New feature or request

Comments

@jerrymarino
Copy link
Contributor

Good afternoon, I'm using Bazel and rules_apple to compile an iOS app and more 馃憤

I've got several third party dependencies. For attribution, I'd like to expose the licenses to users in Settings.app

Is there a way to generate this for all of my deps? I noticed that objc_library ( and all other build rules ) are supposed to have licenses as an attribute.

It wasn't clear to me if this is supported in iOS and I couldn't find anything related in rules_apple or the docs. Previously, this plist was governed by with CocoaPods, which automatically generates this plist, and sets up the bundle. It'd be awesome if Bazel had this ability!

@rahul-malik
Copy link
Contributor

+1, Better licensing support issues seem to be already filed under the bazel repository:
bazelbuild/bazel#1440

@rahul-malik
Copy link
Contributor

@sergiocampama @allevato - Can you provide your thoughts here?

@jerrymarino
Copy link
Contributor Author

Thanks for the pointer @rahul-malik!

@jerrymarino
Copy link
Contributor Author

I think bazelbuild/bazel#1440 is orthogonal to this issue, but could help out a lot.

Acknowledgments.plist and Settings.bundle is pretty specific to Apple development, so maybe it belongs in rules_apple

I've dug into this more and I've discovered that licensing should be at the target level.

With 50 or so third party deps, licensing is defined at the target level and not the package. For example, we've got Texture as a dependency which has several targets in the package. A given target in Testure's build file, Texture_PINRemoteImage depends on targets, say PINRemoteImage which has it's own licensing requirements. Consequently, PINRemoteImage's license does not apply if we don't actually depend on it.

Currently I have achieved this by implementing a parallel structure to the objc_* targets:

  • define a rule, acknowledged_target, which has a value of an acknowledgement_fragment_plist, that contains licensing information.
  • acknowegledged_target, depend on other acknowledged_targets so we can aggregate all of the fragments into acknowledgment_plist
  • define an objc_bundle_library, Settings, which has a resource including acknowledgments_plist
  • define a rule, acknowledgments_plist, which aggregates all of the acknowledged_targets ( and their transitive deps into Acknowledgment.plist

This was some effort to pull off, but it's robust and meets my needs. I'm not sure how reasonable it'd be to integrate this without code generating all of the build files. Still, it is not 100% ideal.

Alternatives Considered:

Another approach could be to create dummy Settings.bundles for each dependency containing the acknowledgment_fragment_plist. Then, merge them together before constructing the final ipa with an ipa preprocessor

Conclusion

I think this feature is a good fit for rules_apple, since Acknowledgments.plist is needed for apps which leverage third party code. I don't think my implementation is upstream able or 100% reasonable.

If bazelbuild/bazel#1440 somehow allowed a user to associate a license file with each target, then, they could potentially aggregate those into Acknowledgments.plist at some point in the build graph. I think this would be ideal.

@sergiocampama sergiocampama added P3 Would be nice, but probably next quarter at the earliest type: feature request New feature or request labels Mar 5, 2019
@sergiocampama
Copy link
Contributor

Sounds like this feature is blocked on the bazel issue. For now, manual inclusion sounds like the best workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 Would be nice, but probably next quarter at the earliest type: feature request New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants