Le moyen le plus efficace de faire 22 builds différents

Question

Je suis sur le point de terminer mon premier projet Xcode relativement simple (un installateur personnalisé) et j'ai besoin de faire 22 builds. Oui ce n'était pas une faute de frappe! Ce qui est différent sur chaque build est le PRODUCT_NAME, un fichier source dans le dossier Resources du bundle et une variable indiquant si le logiciel est une version d'évaluation ou non. D'après ce que j'ai lu jusqu'ici, la duplication de la cible existante semble être la façon de le faire quand il y a seulement quelques builds mais est-ce toujours vrai pour 22? Cela semble énormément de travail. Ce que j'avais à l'esprit était un moyen de changer le PRODUCT_NAME, les fichiers source qui sont copiés dans le dossier Resources et le booléen mode d'essai. Mais je suis coincé.

grâce

Answer 1

je serais probablement écrire un script qui a utilisé un modèle de .xcodeproj et sed pour générer toutes les combinaisons nécessaires.

Answer 2

Vous voudrez peut-être vérifier CMake pour maintenir ce grand nombre de versions.

Le script peut certainement faire le travail, mais une fois que le projet se développe à un nombre important de fichiers, ou si vous vous trouvez en changeant le nombre de builds, changer le script pourrait devenir difficile. CMake vous permettra d'organiser ces scripts, il est donc un peu plus facile de faire les modifications dans le futur.

Answer 3

Ma réponse intestinale est que 22 différents builds qui ne diffèrent que par un seul fichier source est faux ...

Ne peut pas le problème être retourné? Incluez toutes les 22 versions différentes de votre application en une seule construction et fournissez 22 fichiers clé/licence différents dans le dossier .app à chaque déblocage de l'une des 22 versions.

Answer 4

Une façon d'y parvenir dans le passé est d'utiliser la localisation. Lorsque vous utilisez les macros aromatisées NSLocalizedString, certaines d'entre elles ont la possibilité de spécifier un nom de table (c'est-à-dire un fichier de chaînes différent de celui par défaut). Ensuite, chaque fois que j'ai besoin d'une construction de marque différente, je crée simplement un nouveau fichier .strings avec les paires clé-valeur appropriées. J'ai alors une cible de construction qui construit le code avec les valeurs par défaut, et une deuxième cible qui prend le code construit et copie le fichier .strings approprié dans son emplacement approprié. Cela fonctionne plutôt bien et nous a permis de gérer de nombreuses variantes de construction.