-
-
Notifications
You must be signed in to change notification settings - Fork 294
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
Variant groups #124
Variant groups #124
Conversation
… added. Without this change, there will be as many PBXBuildFiles are there are files in the PBXVariantGroup. This may not be the neatest way to do this!
I see this breaks the test 'testAddVariantGroupFileToExistingGroup' - but I'd question if this test is correct. At least, with the behaviour that the test is expecting, my Xcode project won't build. |
Additionally I found that I had to add the newly created variant group to the main group or it wouldn't show up in the Xcode project, which I did like this:
This worked, but I'm almost certain it's the incorrect way to handle this in the general case. |
Thanks for the contribution. I need some information before merging this PR.
|
I've been looking through the threads here but I don't get what the status is on PBXVariantGroups? Is this merged or will the feature not be developed? Sorry if I missed something but please enlighten me. Edit: I now see that #113 is open. So I guess this is still in the works sort of? |
Yes, still a feature i want to add, but it requires more time that i
originally thought it would take. Some attempts were made, but not
satisfactory enough.
…On Tue, Mar 13, 2018 at 4:03 PM, Sebastian Buks ***@***.***> wrote:
I've been looking through the threads here but I don't get what the status
is on PBXVariantGroups? Is this merged or will the feature not be
developed? Both this and #113
<#113> are closed but I
don't see the reasons for closing? Sorry if I missed something but please
enlighten me.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#124 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAfVI2dVcEUQZXK93hIVt_DPjE21n8Tnks5td9_HgaJpZM4MGOuW>
.
--
.: Kronenthaler :.
kronenthaler@gmail.com | yahoo.com
|
OK thanks for the info. Would I be stupid to try the variants-group branch? I want to add InfoPlist.strings files only. |
Not at all, go ahead and try, if you can provide feedback it would be valuable. |
This is an amended version of the variant groups branch. I'm not sure if this is the best way to submit changes.
While testing it, I noticed a few issues which are fixed in this pull request:
With these two fixes, I can confirm that the variant groups work as expected for our use case (localising the app icon name by localising the Info.plist file).
But...
One thing I did find is that the system will automatically add the variants to any existing variant group that exists with the same name - even when that variant group is for a different target. For example, our project has a 'tests' target that contains a InfoPlist.strings variant group that's stored in a separate folder. With the system as it is, any InfoPlist.strings files we add to the project get added to this variant group - even though we want to add them for our main target. This code in question is this:
I don't entirely understand how all of this works, but to me this seems like the incorrect - or at least, unexpected behaviour. I believe you should be able to have multiple variant groups for the same file. I've worked around this by removing the exiting variant group.
I also noticed that adding a strings file that's outside the project causes an exception on this line in ProjectFiles.py - I have't fixed this:
library_path = os.path.join(u'$(SRCROOT)', os.path.split(file_ref.path)[0])
AttributeError: 'PBXVariantGroup' object has no attribute 'path'