Quelle est la différence entre `-fembed-bitcode` et BITCODE_GENERATION_MODE?
J'ai mis à jour une bibliothèque statique pour prendre en charge le bitcode, et à partir de mes recherches, j'ai trouvé deux façons d'y parvenir:
- Ajout du
fembed-bitcodeflag à l'option Other C flags dans mon projet Build Settings ( link ) - Ajout d'un paramètre défini par l'utilisateur avec la touche
BITCODE_GENERATION_MODEdéfini surbitcode( link )
Y a-t-il une différence entre ces deux options?
La seule différence que j'ai remarquée est qu'en utilisant fembed-bitcode, la bibliothèque statique résultante pour iphonesimulator sera construite avec le bitcode complet activé (dans mon cas, la taille binaire passe de 5 Mo à 13 Mo, et je peux vérifier la prise en charge du bitcode en utilisant otool), ce qui ne semble pas faire toute différence dans son utilisation.
Lorsque vous générez la bibliothèque normalement, avec ENABLE_BITCODE=YES, Xcode ajoute l'indicateur de génération -fembed-bitcode-marker à toute invocation de clang, en plaçant un bitcode "vide" dans le fichier o final.
Donc, si vous regardez l'action de compilation dans la phase de construction, cela ressemblera à quelque chose comme:
CompileC {build_path} /StaticBitcode/StaticLogger.o StaticBitcode/StaticLogger.m normal armv7 objective-c com.Apple.compilers.llvm.clang.1_0.compiler cd {path}/StaticBitcode export LANG = en_US.US-ASCII export PATH = "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin :/bin:/usr/sbin:/sbin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -Arch armv7 -fmessage-length = 0 -fdiagnostics -show-note-include-stack -fmacro-backtrace-limit = 0 -std = gnu99 -fobjc-arc -fmodules -gmodules -fmodules-cache- [...] - fembed- marqueur de code-bit [...]
Cela est vrai pour l'action de génération (indépendante de la cible).
Quand vous Build & Archive, les -fembed le drapeau est remplacé par -fembed-bitcode, qui crée vraiment un binaire activé par Bitcode:
CompileC {build_path} /StaticBitcode/StaticLogger.o StaticBitcode/StaticLogger.m normal armv7 objective-c com.Apple.compilers.llvm.clang.1_0.compiler cd {path}/StaticBitcode export LANG = en_US.US-ASCII export PATH = "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin :/bin:/usr/sbin:/sbin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -Arch armv7 -fmessage-length = 0 -fdiagnostics -show-note-include-stack -fmacro-backtrace-limit = 0 -std = gnu99 -fobjc-arc -fmodules -gmodules -fmodules-cache- [...] - fembed- bitcode [...]
drapeau fembed-bitcode
Étant donné que, si vous ajoutez le -fembed-bitcode drapeau aux autres drapeaux C, vous enverrez deux drapeaux au compilateur pendant la compilation. Cela peut faire taire certains avertissements que vous pouvez recevoir lorsque vous utilisez la bibliothèque liée sur un autre projet. Mais, vous devez vérifier si vous obtenez le comportement attendu. :)
(Lorsque j'ai testé en utilisant le -fembed-bitcode sur les autres drapeaux C, Xcode a donné l'avertissement clang: warning: argument unused during compilation: '-fembed-bitcode-marker')
BITCODE_GENERATION_MODE
D'autre part,
Si vous définissez BITCODE_GENERATION_MODE=bitcode Sur ton User-defined Setting, même pendant la phase de construction, les fichiers seront compilés à l'aide de l'indicateur -fembed-bitcode.
Et, si vous définissez BITCODE_GENERATION_MODE=marker, les fichiers seront compilés à l'aide de l'indicateur -fembed-bitcode-marker, indépendamment de la phase d'action.
Donc, si vous souhaitez activer le bitcode pour chaque action (génération et archivage), la meilleure façon de le faire est d'utiliser le BITCODE_GENERATION_MODE réglage.