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

Update external frameworks' plist file #1036

Closed
wants to merge 2 commits into from
Closed

Conversation

kipbits
Copy link

@kipbits kipbits commented Dec 29, 2015

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

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
@Bromeon
Copy link
Member

Bromeon commented Dec 29, 2015

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.

@kipbits
Copy link
Author

kipbits commented Dec 29, 2015

still learning the desktop client. couldn't see an easier way to do this. this is the last one

@mantognini mantognini changed the title osx-ext-framework-plist-update from(REDO) Update external frameworks' plist file Dec 30, 2015
@mantognini
Copy link
Member

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 sfml-*.framework as well. Isn't this an issue for signing product?

@mantognini
Copy link
Member

But I'm wondering if this property should also be added to sfml-*.framework as well. Isn't this an issue for signing product?

@kipbits did you have any issue with SFML frameworks themselves, or only its dependencies? (Or did you use dylibs instead of frameworks?)

@kipbits
Copy link
Author

kipbits commented Jan 18, 2016

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.

@mantognini
Copy link
Member

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
@mantognini
Copy link
Member

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). ;-)

@kipbits
Copy link
Author

kipbits commented Aug 1, 2016

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.

@mantognini
Copy link
Member

It also has my fix for the american keyboard in it.

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. ;-)

I can't tell you about SFML.Framework.

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 sfml-system.framework, sfml-window.framework, sfml-graphics.framework, sfml-network.framework and sfml-audio.framework there might be an issue similar to the one for SFML's dependencies that are shipped as frameworks.

if you give me some time I might be able to separate the plist issue from the keyboard issue.

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!

@kipbits
Copy link
Author

kipbits commented Aug 2, 2016

ok i will see if i can separate the issues. ill try and submit a pr by the end of the week

@kipbits
Copy link
Author

kipbits commented Aug 5, 2016

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:
the change to info.plist is really easy to do in any text editor after the fact, and is not necessary for testing on ones own machine. Anyway, i think it will take me awhile to get around to, so if someone else wants to make the changes for me...

I'm sure the plists will change in the not to distant future anyway

@mantognini
Copy link
Member

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.

@kipbits
Copy link
Author

kipbits commented Aug 5, 2016

sure will, note: might take me some time.(sorry about that)

mantognini added a commit that referenced this pull request Feb 20, 2017
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.
mantognini added a commit that referenced this pull request Feb 20, 2017
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.
@mantognini
Copy link
Member

Superseded by #1194.

@mantognini mantognini closed this Feb 20, 2017
mantognini added a commit that referenced this pull request Feb 20, 2017
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.
@eXpl0it3r eXpl0it3r added this to the 2.5 milestone Feb 20, 2017
@eXpl0it3r eXpl0it3r added this to Discussion in SFML 2.5.0 Feb 21, 2017
@eXpl0it3r eXpl0it3r moved this from Discussion to Merged in SFML 2.5.0 Feb 21, 2017
iamPHEN pushed a commit to Bablawn3d5/SFML that referenced this pull request Mar 11, 2017
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
SFML 2.5.0
  
Merged / Superseded
Development

Successfully merging this pull request may close these issues.

None yet

4 participants