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
Update external frameworks' plist file #1036
Conversation
OSX external framework Info.plist update for Mac App Store validation squash 7 commits: Does this fix it? SFML#1033 (comment) SFML#1020 http://en.sfml-dev.org/forums/index.php?topic=19498.msg140542#msg140542
We have already told you this, but you don't have to create a new pull request for every single change. You can edit your commits. Please consider this advice, it's really not necessary that the whole discussion is moved from one PR to the next every half day. I really hope this is the last PR for this feature, 9 is definitely enough. Don't prematurely open pull requests in the future, it adds useless work for us and confuses everybody. |
still learning the desktop client. couldn't see an easier way to do this. this is the last one |
The commit message format doesn't match what we are used to around here, but that's more of a detail. The content on the other hand seems fine. But I'm wondering if this property should also be added to |
@kipbits did you have any issue with SFML frameworks themselves, or only its dependencies? (Or did you use dylibs instead of frameworks?) |
i did use dylibs. I don't know if that means the frameworks need the same job done? I'm still trying to get receipt validation working before I finally submit for app review. |
I guess the other frameworks will deserve the same patch then. However, it's a bit more tricky due to the fact they are generated by cmake. This might become handy. |
…and dash) fixed tilde and dash. removed associated warnings tilde 0x0a -> 0x32 dash 0x32 -> 0x1b
Bumping this. @kipbits did you have time to investigate further? A full patch is still welcome (but only one PR/issue, please avoid mixing two subjects in one PR). ;-) |
hey, almost forgot about this. i have the changes in my own fork. It also has my fix for the american keyboard in it. I can't tell you about SFML.Framework. I'ts kindof been awhile, and while they do work on my machine, I cant tell you if they will work as a part of a package. I can try and submit a pull request for what i have, or if you give me some time I might be able to separate the plist issue from the keyboard issue. |
That's why I said but only one PR/issue, please avoid mixing two subjects in one PR. You can use branches to separate the two issues, and even merge the two in your own master branch if you'd like. But make sure the PR you open only "solve" one issue at a time. That makes things easier in discussions. ;-)
For this specific framework, there's no issue because it's a header only framework that doesn't have to be shipped with your app. However, for
Please, take your time. ;-) But I'd rather be sure that what you submit is actually solving something -- otherwise it just adds something to maintain for nothing. So if you could test the submission process with all those frameworks instead of dylibs, that'd be awesome! (I don't have an account myself, nor does anyone in the SFML team so we can only rely on users' feedback and help for that.) BTW, could you update this PR instead of opening a new one. That way we keep the discussion in one place only. Thanks! |
ok i will see if i can separate the issues. ill try and submit a pr by the end of the week |
Sorry Guys, I've tried to separate my commits into 2 separate branches. Githubdesktop is really a pain. I couldn't see how to do this without deleting what i've done for HIDinputmanager. github only lets me have one fork of any repository at a time, and i'd rather not lose what i did for keyboard. On the plus side: I'm sure the plists will change in the not to distant future anyway |
The github client is indeed a bit limited. I personally use Source Tree but GitKraken looks more than decent too. The command line is also a good alternative when the GUI clients are too limited. BTW, you don't need to fork SFML twice but simply use more branches. Let us know when you achieve something. |
sure will, note: might take me some time.(sorry about that) |
This should improve the signing process of Mac Applications. This improves the frameworks of external dependencies used by SFML. To patch sfml-*.framework, one would need to customised the `MACOSX_FRAMEWORK_INFO_PLIST` cmake property and provide a custom Info.plist file with CFBundleSupportedPlatforms property set. See https://cmake.org/cmake/help/latest/prop_tgt/FRAMEWORK.html This is however not required (probably) if one used dylibs instead. Related to #1020 and #1036. Credits go to @1036.
This should improve the signing process of Mac Applications. This improves the frameworks of external dependencies used by SFML. To patch sfml-*.framework, one would need to customised the `MACOSX_FRAMEWORK_INFO_PLIST` cmake property and provide a custom Info.plist file with CFBundleSupportedPlatforms property set. See https://cmake.org/cmake/help/latest/prop_tgt/FRAMEWORK.html This is however not required (probably) if one used dylibs instead. Related to #1020 and #1036. Credits go to @kipbits.
Superseded by #1194. |
This should improve the signing process of Mac Applications. This improves the frameworks of external dependencies used by SFML. To patch sfml-*.framework, one would need to customised the `MACOSX_FRAMEWORK_INFO_PLIST` cmake property and provide a custom Info.plist file with CFBundleSupportedPlatforms property set. See https://cmake.org/cmake/help/latest/prop_tgt/FRAMEWORK.html This is however not required (probably) if one used dylibs instead. Related to #1020 and #1036. Credits go to @kipbits.
This should improve the signing process of Mac Applications. This improves the frameworks of external dependencies used by SFML. To patch sfml-*.framework, one would need to customised the `MACOSX_FRAMEWORK_INFO_PLIST` cmake property and provide a custom Info.plist file with CFBundleSupportedPlatforms property set. See https://cmake.org/cmake/help/latest/prop_tgt/FRAMEWORK.html This is however not required (probably) if one used dylibs instead. Related to SFML#1020 and SFML#1036. Credits go to @kipbits.
OSX external framework Info.plist update for Mac App Store validation
squash 7 commits: Does this fix it?
pull/1033#
issues/1020
forum topic on app upload