Liste de questions
- commande pod spec lint, lors de la vérification du code et de la configuration du pod, il est compilé à partir du code extrait de git; donc si git n'est pas créé, l'erreur suivante sera signalée:
-> ServyouCocoaPodDynamicLayout (0.1.0)
- ERROR | [iOS] unknown: Une erreur inconnue a été rencontrée ([!] /Applications/Xcode.app/Contents/Developer/usr/bin/git clone http://192.168.110.114/jihq/ServyouCocoaPodDynamicLayout.git / var / folders / rg / f1ycrs553dq2z2dh0000 / d20160921-12602-1bx4f8v –template = –single-branch –depth 1 –branch 0.1.0
Clonage dans '/ var / folders / rg / f1ycrs553dq2z2dq7mt0mbh80000gn / T / d20160921-12602-1bx4f8v' ...
remote: Not Found
fatal: repository ' http://192.168.110.114/jihq/ServyouCocPodDynamicLay trouvé
lors de la recherche. validation.
Si le code n'est pas téléchargé sur git, l'erreur suivante sera signalée:
-> ServyouCocoaPodDynamicLayout (0.1.0)
- ERROR | [iOS] unknown: Une erreur inconnue a été rencontrée ([!] /Applications/Xcode.app/Contents / Developer / usr / bin / git clone http://192.168.110.114/jihq/servyoucocoapoddynamiclayout.git / var / folders / rg / f1ycrs553dq2z2dq7mt0mbh80000gn / T / d20160921-12686-1o6vj1q --template = --singledepth - 1 - branche 0.1.0
Clonage dans '/ var / folders / rg / f1ycrs553dq2z2dq7mt0mbh80000gn / T / d20160921-12686-1o6vj1q' ...
fatal: branche distante 0.1.0 introuvable dans l'origine amont
) lors de la validation.
Si la valeur de balise correspondante n'est pas ajoutée sur git, une erreur sera signalée comme ci-dessus.
2. répertoire de fichiers le répertoire
par défaut est défini sur le fichier d'en-tête: s.public_header_files = 'Pod / Classes / ** /*.h'; mais si le répertoire Classes, votre hiérarchie de dossiers de code sur deux, il y aura l'erreur suivante:
-ERREUR | Modèles de fichier [iOS]: Le public_header_filesmodèle ne correspond à aucun fichier.
Ceci est dû au fait que la hiérarchie des dossiers est trop peu profonde et que le fichier correspondant est introuvable. Si votre hiérarchie de dossiers comporte trois niveaux, vous devez la modifier en: s. public_header_files = 'Pod / Classes / * * / * * /*.h';
pour soumettre le fichier de code modifié 3.
problème 1 disons, la commande lint est une extraction de fichiers de git, donc les fichiers sont git prévaudra. Par exemple, si vous ajoutez un nouveau fichier image dans le répertoire Assets local, mais que vous ne poussez pas vers git, les problèmes suivants se produiront:
-ERREUR | Modèles de fichier [iOS]: Le resource_bundlesmodèle pour ServyouCocoaPodDynamicLayoutne correspond à aucun fichier.
Évidemment, le fichier de configuration podspec est correct, la mise à jour du pod local -no-repo-update est possible, mais lint réussit, ce n'est pas à cause du fichier correspondant sur Git;
4. source configurée
pour utiliser la source du fichier de configuration par défaut: S.source_files = 'ServyouCocoaPodDynamicLayout / Classes / * / ; L'
erreur suivante peut être signalée : -ERROR
| [iOS] unknown: Une erreur inconnue a été rencontrée (méthode non définie / var / folders / rg / f1ycrs553dq2z2dq7mt0mbh80000gn / T / CocoaPods / Lspace / App .xcintpath' for nil:NilClass) during validation.
根据github的issue说明，这可能是cocoapod的bug，可以将配置改为：
s.source_files = 'ServyouCocoaPodDynamicLayout/Classes/**/**/*.{h,m}'
5. 如果当前pod基于其他私有pod，则每个需要其功能的单元都需要import其头文件；否则可能出现以下问题：
error: no known class method for selector 'xxx:'
6. 出现expected a type问题
出现如下问题：
- ERROR | [iOS] xcodebuild: ServyouCocoaPodDynamicLayout/ServyouCocoaPodDynamicLayout/Classes/DynamicLayout/DynamicLayoutModel/SVDynamicLayoutManager.h:37:57: error: expected a type
最开始看到该问题时，以为是Foundation框架没有引用进pod中，所以就在.m代码里import了头文件，然后s.framework里添加了Foundation，但都没有用；
然后在lint命令后加了 --verbose参数，看详细的出错日志，发现是在这里出现的错误：
/var/folders/rg/f1ycrs553dq2z2dq7mt0mbh80000gn/T/CocoaPods/Lint/Pods/ServyouCocoaPodDynamicLayout/ServyouCocoaPodDynamicLayout/Classes/DynamicLayout/DynamicLayoutModel/SVDynamicLayoutManager.h:99:39: error: expected a type
WithModel:(NSManagedObject *)modelDO;
错误的地方是NSManagedObject，然后我看了代码，发现该对象属于CoreData框架，但我的这部分功能依赖于基础的pod；所以按说不需要关心CoreData框架；可我看了之后才发现基础pod的podspec文件中并没有配置CoreData框架。。。。而且还竟然校验通过了。
我尝试着在自己的pod中引用CoreData的头文件，在s.framework中加入CoreData，但都没有效果。
没办法，我只能自己修改了基础的pod的配置。然后更新了私有仓库，可是问题依旧存在。
后来偶然运行了一下下面的命令：pod spec lint ServyouCocoaPodDynamicLayout.podspec --sources=ServyouCocoaPod_IOS,master --no-clean
然后看到了这样一句日志：
Pods workspace available atfor inspection.
这个App.xcworkspace工作空间就是本地编译pod的工程，进入对应的目录，打开工程，编译，就可以看到日志中提示的错误。
我这时候才注意到，之前的错误日志中有一个地方被我忽视了：
- ERROR | [iOS] xcodebuild: ServyouCocoaPodDynamicLayout/ServyouCocoaPodDynamicLayout/Classes/DynamicLayout/DynamicLayoutModel/SVDynamicLayoutManager.h:37:57: error: expected a type
那就是错误的地方是.h文件。而我之前一直关注的.m文件。。在工程里面我很容易就发现出错的原因是因为缺少前向引用，只要用@class进行一些声明就可以解决上面的问题。
以前之所以没有这样的问题是因为在pch文件中统一引用了头文件，现在没有了pch文件，所以.h文件里便找不到对应类的声明，出现了expected a type的错误。
7. 解决了以上问题后就出现了下面两个问题：
/Users/jifeng/Library/Developer/Xcode/DerivedData/App-dpxkmrruvfndhjfuqdoultvoaiad/Build/Products/Release-iphonesimulator/ServyouCocoaPodDynamicLayout/ServyouCocoaPodDynamicLayout.framework/Headers/SVDynamicLayoutManager.h:9:9: error: include of non-modular header inside framework module 'ServyouCocoaPodDynamicLayout.SVDynamicLayoutManager' [-Werror,-Wnon-modular-include-in-framework-module]
\#import "SVObject.h"
^
1 error generated.
/var/folders/rg/f1ycrs553dq2z2dq7mt0mbh80000gn/T/CocoaPods/Lint/App/main.m:3:9: fatal error: could not build module 'ServyouCocoaPodDynamicLayout'
@import ServyouCocoaPodDynamicLayout;
~~~ ^~~~~~~~~~~~~~~~~~~~~~
2 erreurs générées. Après avoir
rencontré ce problème, j'ai cherché sur Internet "inclure un en-tête non modulaire à l'intérieur du module du cadre". La solution est la suivante: Définissez Autoriser les modules non modulaires inclus dans l'infrastructure dans les paramètres de construction sur OUI, mais la cause du problème n'a pas été mentionnée.
Plus tard, j'ai vu un article dans un petit livre qui expliquait brièvement la cause du problème et proposait une autre solution: http://www.jianshu.com/p/a1d2d148fdd3
En termes simples, il s'agit d'écrire du code dans le fichier podfile et de générer il modulemap et fichiers parapluie dynamiquement.
Au final, j'ai senti que la deuxième solution était un peu délicate, j'avais peur qu'il y ait des problèmes à l'avenir, j'ai donc décidé d'adopter la première méthode.
Tout d'abord, vérifiez le projet de compilation via le paramètre --no-clean de la commande lint, et modifiez manuellement le paramètre de compilation mentionné dans la première solution.Après avoir changé en OUI, il n'y a en effet aucun problème.
Cependant, la création d'un pod ne peut évidemment pas modifier le paramètre manuellement, je l'ai donc vérifié sur la page Web officielle d'introduction de la syntaxe podspec https://guides.cocoapods.org/syntax/podspec.html, et j'ai finalement trouvé trois paramètres associés possibles dans les paramètres de construction. : Compilateur \ _flags, pod \ _target \ _xcconfig, utilisateur \ _target \ _xcconfig.
Essayez d'abord de configurer le compilateur \ flags. Parce que l'exemple officiel est spec.compiler_flags = '- DOS_OBJECT_USE_OBJC = 0', '- Wno-format'
Et il y a un -Wnon-modular-include-in-framework-module similaire dans mon message d'erreur, j'ai donc configuré spec.compiler_flags = '- Wnon-modular-include-in-framework-module', mais cela n'a pas fonctionné .
Essayez ensuite de configurer le pod \ _target \ _xcconfig. L'exemple officiel est: spec.pod_target_xcconfig = {'OTHER_LDFLAGS' => '- lObjC'}. Cela doit être le paramètre Autres indicateurs de lien dans les paramètres de construction correspondants. Bien que je sache que c'est probablement faux, j'essaie toujours de définir spec.pod_target_xcconfig = {'OTHER_LDFLAGS' => '- Wnon-modular-include-in-framework-module'}. Cela n'a vraiment pas fonctionné. {} dans la configuration doit être une configuration de type dictionnaire, => la chaîne précédente est une valeur de clé, vous devez maintenant trouver la valeur de clé correspondante de Allow Non-modular includes In Framework Modules. Dans l'aide rapide de Xcode, j'ai vu la déclaration CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES dans le commentaire. J'ai essayé spec.pod_target_xcconfig = {'CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES'} et n'ai trouvé aucun effet. Plus tard, j'ai pensé que Xcode pouvait être compilé via la ligne de commande et qu'il pouvait y avoir une valeur de clé correspondante dans l'instruction de compilation. Ensuite, bien que la valeur de clé correspondante n'ait pas été trouvée directement, j'ai vu que xcodebuild avait le paramètre -showBuildSettings pour afficher les paramètres de compilation. Donc, commencez par définir manuellement Autoriser les modules inclus dans l'infrastructure non modulaire dans le projet de compilation sur OUI. Ensuite, via l'application xcodebuild -workspace. workspace -scheme App -showBuildSettings a examiné tous les paramètres du projet en cours et a vraiment trouvé que la valeur d'une telle constante CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES est OUI. L'instruction dans l'aide rapide est la valeur de clé correcte, mais la configuration de pod \ _target \ _xcconfig ne fonctionne pas.
Enfin, essayez de configurer user \ _target \ _xcconfig. Selon l'exemple officiel, la configuration est: spec.user_target_xcconfig = {'CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES' => 'OUI'}. En cas de succès, seul l'avertissement est laissé pour la commande lint.
Cependant, en regardant l'explication officielle, la différence entre user \ _target \ _xcconfig et pod \ _target \ _xcconfig est que l'utilisateur \ _target \ _xcconfig est le paramètre pour tous les pods du projet compilé, tandis que pod \ _target \ _xcconfig est uniquement pour le pod actuel. Par conséquent, si la même valeur de user \ _target \ _xcconfig est définie dans le podspec de plusieurs pods, il peut y avoir des conflits. Mais comme CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES ne fonctionne pas dans le pod \ _target \ _xcconfig, il ne peut être traité que selon la configuration actuelle.
8. Il peut y avoir deux entrepôts privés lorsqu'ils sont tirés localement.
Étant donné que git a deux adresses, git et http / https, parfois deux référentiels basés sur le même git peuvent apparaître sous les dépôts locaux, avec des noms d'entrepôt différents. Étant donné que le nom de l'entrepôt a été spécifié au début de Lint, il peut être transmis, mais lorsque le pod repo push est spécifié, le nom de l'entrepôt push est spécifié, mais parce que le nom de l'entrepôt de vérification n'est pas spécifié, une fois que votre pod dépend de l'entrepôt privé Une erreur similaire à [!] Plusieurs spécifications ont été trouvées pourSVLibrary (2.2.0) `: apparaîtra lors de la vérification. À ce stade, vous devez supprimer un entrepôt privé, puis pousser à nouveau.
9. Utiliser des pods d'entrepôt privés dans podfile
Ajoutez simplement le pod xxx, vous serez invité à indiquer que xxx est introuvable. À ce stade, vous devez ajouter le git de l'entrepôt privé et de l'entrepôt officiel.
'[email protected]. Source . : XXX / servyoucocoapod_ios.git'
Source ' https://github.com/CocoaPods/Specs.git '
10. Le modèle des documents CoreData disposés dans les Resouce
s.resource_bundles = {
'Images' => ['Pod / Assets / *. Png'],
'Models' => ['Pod / Classes / / /*.{xcdatamodeld,xcdatamodel}']
}
S'il n'est pas configuré, aucun fichier momd ne peut être trouvé dans l'application bundle.
Selon la configuration ci-dessus, le répertoire final de votre modèle est:
Frameworks / CocoaPodXXX.framework / Models.bundle / xxx.momd
, vous devez faire attention lorsque vous obtenez le chemin du fichier dans le code.