-
Notifications
You must be signed in to change notification settings - Fork 38
Make an Info.plist template for UIAppFonts #70
Comments
See also SwiftGen/SwiftGen#324 |
Those "Delete", "Add" and "Merge" commands work that way? TIL |
Yup just tested that with a dummy plist. I don't think there's another way to just replace the content of an array in a PLIST other than trying to delete, then add empty entry then merge. Just merge would just add to existing, with duplicating every time. I haven't seen an option for replacing with content of a file in one command |
Another option would be to make the template not generate the partial #!/bin/sh
/usr/libexec/PlistBuddy -c "Delete UIAppFonts" -c "Add UIAppFonts array"{% for font in fonts %} -c "Add UIAppFonts: string '{{font.path}}'"{% endfor %} "$INFOPLIST_PATH" And then people could just |
Hey, when we have the pipe support (context loading and output), we can combine commands: |
You mean generate the Fonts JSON context once, then use that context to generate the Fonts Swift constants in one hand, the Info.plist keys on another hand? Or you mean use the pipe just for Info.plist synching, by generating the UIAppFonts keys in stdout and piping that to insert in Info.plist without an intermediate file? If that's the latter, I don't think we'd use SwiftGen to inject the UIAppFonts entry in the Info.plist. We should still use |
Ehm, I mean:
|
But if plistbuddy already accepts from stdin and a file at the same time --> better |
I was actually looking at that, PlistBuddy doesn't seem to accept reading from stdin out of the box. We should investigate more. But as I said, your 2nd point — which seems to be what I originally understood you meant — isn't a reliable solution. You're referring to the open PRs adding the For example, XML comments, CDATA encoding, etc, could potentially be lost in the process of parsing the input then trying to regenerate the same output from the parsed input. That's the same as if you tried to convert a PNG to a JPEG then back to a PNG, you'd lose some info in the process, especially because of the intermediate step during the conversion (which in our case would be the Stencil context). So I don't think using the future |
Right, didn't think of binary plists, or other data. But keep in mind that info.plist is parsed and edited by Xcode, so that too probably throws away any comments and other stuff. The plist (and json) parsers don't do anything more than loading those entire dictionaries/arrays into a context, and the template could just go through that structure, and when it finds the key But you're right, I might be trying to do stuff the hard way instead of using existing tools. Just thinking of the possibilities 😄 |
Found the trick to use with pipe and avoid the intermediate file: The template will look like this, generating the commands for
And the user can call SwiftGen that way — using the template to generate swiftgen font -t InfoPlist Resources/Fonts | /usr/libexec/PlistBuddy "$INFOPLIST_PATH" >/dev/null And that's it! 🎉
|
To answer @bsarrazin 's questions/concerns, one could also imagine using those templates and still some commands in the Script Build Phase on every build… but just to warn in case the UIAppFonts keys differ, without auto-modifying the For example one could use such a Script Build Phase: # Generate the UIAppFonts.plist file, an simple plist with only the UIAppFonts key auto-generated
swiftgen -t UIAppFonts Resources/Fonts -o Generated/UIAppFonts.plist
# Compare the current content of the Info.plist's UIAppFonts key with the generated UIAppFonts.plist
# and emit an Xcode warning if they differ
if (/usr/libexec/PlistBuddy -c "Print UIAppFonts" "$INFOPLIST_FILE" | diff -q Generated/UIAppFonts.plist -); then
echo "$INFOPLIST_FILE 's UIAppFonts key seems up-to-date"
else
echo "warning: Some fonts are missing in the UIAppFonts key of $INFOPLIST_FILE. Copy/Paste the content of Generated/UIAppFonts.plist in that Info.plist file to update the list."
fi With that kind of script, if the So in the end once again developers can do whatever they want with that generated |
It would be nice to have a template able to auto-generate the content of the
UIAppFonts
key.People could then generate the partial
plist
usingswiftgen
, then use e.g.PlistBuddy
to merge that with their actual Info.plist:(Note: The second step here is automated using
PlistBuddy
, but in practice the developer might prefer just doing that step manually, by opening theUIAppFonts.plist
file in Xcode, and copy/pasting that entry in theirInfo.plist
manually)The template to generate the UIAppFonts plist could look like this:
The text was updated successfully, but these errors were encountered: