-
Notifications
You must be signed in to change notification settings - Fork 395
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Specifically suppress setPrimitiveType: generation -- apparently it t…
…riggers Apple's piss-poor private-API-use detector when submitting to the App Store. Closes #16.
- Loading branch information
Showing
4 changed files
with
13 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Binary file not shown.
Binary file not shown.
cd9809d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @rentzsch, this change has seemingly broken things for me when using attributes of Integer type.
The machine implementation includes these methods (where I have an intAttribute attribute) which is causing Xcode to throw an error about
primitiveIntAttribute
andsetPrimitiveIntAttribute
not existing.Changing back to use noninheritedAttributes puts the method declarations back and obviously fixes things. Though, if Apple have problems with it… :-/
cd9809d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm I'm not understanding the problem, or at least I can't reproduce it in the Test Dir. This work-around should only deal with attributes named "type" and "intAttribute" surely doesn't match that.
Can you repro the issue with the Test Dir?
cd9809d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah! I think I've been stupid, I'm still running the last version of mogenerator using the updated templates, my bad. :-/
cd9809d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem, it can be problematic keeping them in sync. Hence why the default templates are built into the binary itself nowadays.
cd9809d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a quick way to get to the version of templates that ship with the current binary? I copied the templates out of GitHub to make some changes and ran into the same issue, and them came across these commit notes when I figured out what the issue was... I'd like to make sure changes I make are only against templates that match the shipping binaries so others can use them with the shipping version of mogenerator.
cd9809d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @KiGi, the best way in my mind would be to clone the repository and checkout the 1.27 tag. Once this is checked out, you can make a branch to work on and modify the templates. When a new version of mogenerator is released, you can then merge it into your branch and this will allow your modified template to get the updates that have been made since 1.27. Hope this helps.