Créez une bibliothèque statique épaisse (appareil + simulateur) à l'aide de Xcode et du SDK 4+


283

Il semble que nous pouvons - théoriquement - construire une bibliothèque statique unique qui comprend à la fois un simulateur et un iPhone et un iPad.

Cependant, Apple ne dispose d'aucune documentation à ce sujet et les modèles par défaut de Xcode ne sont PAS configurés pour ce faire.

Je recherche une technique simple, portable et réutilisable qui peut être effectuée dans Xcode.

Un peu d'histoire:

  • En 2008, nous pouvions créer des bibliothèques statiques uniques comprenant à la fois la carte SIM et l'appareil. Apple l'a désactivé.
  • Tout au long de 2009, nous avons créé des paires de bibliothèques statiques - une pour la simulation, une pour le périphérique. Apple a désormais désactivé cela également.

Références:

  1. C'est une excellente idée, c'est une excellente approche, mais cela ne fonctionne pas: http://www.drobnik.com/touch/2010/04/universal-static-libraries/

    • Il y a quelques bogues dans son script qui signifient que cela ne fonctionne que sur sa machine - il devrait utiliser BUILT_PRODUCTS_DIR et / ou BUILD_DIR au lieu de les "évaluer".)
    • Le dernier Xcode d'Apple vous empêche de faire ce qu'il a fait - cela ne fonctionnera tout simplement pas, en raison du changement (documenté) dans la façon dont Xcode traite les cibles)
  2. Un autre intervenant SO a demandé comment le faire SANS xcode et avec des réponses axées sur la partie arm6 vs arm7 - mais a ignoré la partie i386: comment compiler une bibliothèque statique (fat) pour armv6, armv7 et i386

    • Depuis les derniers changements d'Apple, la partie Simulator n'est plus la même chose que la différence arm6 / arm7 - c'est un problème différent, voir ci-dessus)

Je me demandais simplement - pourquoi voudriez-vous cela? Cela ne rend-il pas la bibliothèque d'appareils plus grande et plus lourde sur l'appareil?
cregox

3
@Cawas - le "poids" de la bibliothèque n'est pas pertinent dans 95% des situations du monde réel - pour la plupart d'entre nous, les bibliothèques sont minuscules, en particulier comparées, par exemple, à l'affichage d'un seul UIImageView.
Adam

1
@Cawas - pendant ce temps, la valeur ici est que vous rendez BEAUCOUP plus facile pour d'autres personnes d'utiliser / réutiliser votre bibliothèque. Cela devient un processus de glisser / déposer en une étape.
Adam

4
@Cawas - enfin, un avantage étonnamment précieux: il est si facile d'envoyer accidentellement à quelqu'un la "mauvaise" bibliothèque compilée - XCode n'effectue aucune vérification et compilera volontiers la "mauvaise" architecture dans le fichier nommé que vous pensiez être le "correct" architecture. Apple continue de casser Xcode dans ce domaine - chaque nouvelle version a des changements qui signifient que "le bouton sur lequel vous avez appuyé hier pour compiler correctement votre bibliothèque le compilera aujourd'hui incorrectement". Jusqu'à ce qu'Apple cesse de nous déranger, nous devons protéger leur mauvaise interface utilisateur de l'idiot :).
Adam

1
Ce serait vraiment génial! Parce qu'en ce moment, nous ne pouvons tout simplement pas compter sur le simulateur pour quelque chose de plus complexe.
cregox

Réponses:


272

ALTERNATIVES:

Copier / coller facile de la dernière version (mais les instructions d'installation peuvent changer - voir ci-dessous!)

La bibliothèque de Karl prend beaucoup plus d'efforts à configurer, mais une solution à long terme beaucoup plus agréable (elle convertit votre bibliothèque en un Framework).

Utilisez-le, puis ajustez-le pour ajouter la prise en charge des versions d'archives - voir le commentaire de @ @ Frederik ci-dessous sur les modifications qu'il utilise pour que cela fonctionne correctement avec le mode Archive.


MODIFICATIONS RÉCENTES: 1. Ajout de la prise en charge d'iOS 10.x (tout en maintenant la prise en charge des anciennes plates-formes)

  1. Informations sur la façon d'utiliser ce script avec un projet intégré dans un autre projet (bien que je recommande fortement de ne PAS le faire, jamais - Apple a quelques bogues de blocage dans Xcode si vous intégrez des projets les uns dans les autres, à partir de Xcode 3.x à Xcode 4.6.x)

  2. Script bonus pour vous permettre d'inclure automatiquement des bundles (c'est-à-dire inclure des fichiers PNG, des fichiers PLIST, etc. de votre bibliothèque!) - voir ci-dessous (faites défiler vers le bas)

  3. prend désormais en charge iPhone5 (en utilisant la solution de contournement d'Apple pour les bogues dans lipo). REMARQUE: les instructions d'installation ont changé (je peux probablement simplifier cela en changeant le script à l'avenir, mais je ne veux pas le risquer maintenant)

  4. La section "copier les en-têtes" respecte désormais le paramètre de construction pour l'emplacement des en-têtes publics (avec l'aimable autorisation de Frederik Wallner)

  5. Ajout du paramètre explicite de SYMROOT (peut-être que OBJROOT doit également être défini?), Grâce à Doug Dickinson


SCRIPT (c'est ce que vous devez copier / coller)

Pour les instructions d'utilisation / d'installation, voir ci-dessous

##########################################
#
# c.f. /programming/3520977/build-fat-static-library-device-simulator-using-xcode-and-sdk-4
#
# Version 2.82
#
# Latest Change:
# - MORE tweaks to get the iOS 10+ and 9- working
# - Support iOS 10+
# - Corrected typo for iOS 1-10+ (thanks @stuikomma)
# 
# Purpose:
#   Automatically create a Universal static library for iPhone + iPad + iPhone Simulator from within XCode
#
# Author: Adam Martin - http://twitter.com/redglassesapps
# Based on: original script from Eonil (main changes: Eonil's script WILL NOT WORK in Xcode GUI - it WILL CRASH YOUR COMPUTER)
#

set -e
set -o pipefail

#################[ Tests: helps workaround any future bugs in Xcode ]########
#
DEBUG_THIS_SCRIPT="false"

if [ $DEBUG_THIS_SCRIPT = "true" ]
then
echo "########### TESTS #############"
echo "Use the following variables when debugging this script; note that they may change on recursions"
echo "BUILD_DIR = $BUILD_DIR"
echo "BUILD_ROOT = $BUILD_ROOT"
echo "CONFIGURATION_BUILD_DIR = $CONFIGURATION_BUILD_DIR"
echo "BUILT_PRODUCTS_DIR = $BUILT_PRODUCTS_DIR"
echo "CONFIGURATION_TEMP_DIR = $CONFIGURATION_TEMP_DIR"
echo "TARGET_BUILD_DIR = $TARGET_BUILD_DIR"
fi

#####################[ part 1 ]##################
# First, work out the BASESDK version number (NB: Apple ought to report this, but they hide it)
#    (incidental: searching for substrings in sh is a nightmare! Sob)

SDK_VERSION=$(echo ${SDK_NAME} | grep -o '\d\{1,2\}\.\d\{1,2\}$')

# Next, work out if we're in SIM or DEVICE

if [ ${PLATFORM_NAME} = "iphonesimulator" ]
then
OTHER_SDK_TO_BUILD=iphoneos${SDK_VERSION}
else
OTHER_SDK_TO_BUILD=iphonesimulator${SDK_VERSION}
fi

echo "XCode has selected SDK: ${PLATFORM_NAME} with version: ${SDK_VERSION} (although back-targetting: ${IPHONEOS_DEPLOYMENT_TARGET})"
echo "...therefore, OTHER_SDK_TO_BUILD = ${OTHER_SDK_TO_BUILD}"
#
#####################[ end of part 1 ]##################

#####################[ part 2 ]##################
#
# IF this is the original invocation, invoke WHATEVER other builds are required
#
# Xcode is already building ONE target...
#
# ...but this is a LIBRARY, so Apple is wrong to set it to build just one.
# ...we need to build ALL targets
# ...we MUST NOT re-build the target that is ALREADY being built: Xcode WILL CRASH YOUR COMPUTER if you try this (infinite recursion!)
#
#
# So: build ONLY the missing platforms/configurations.

if [ "true" == ${ALREADYINVOKED:-false} ]
then
echo "RECURSION: I am NOT the root invocation, so I'm NOT going to recurse"
else
# CRITICAL:
# Prevent infinite recursion (Xcode sucks)
export ALREADYINVOKED="true"

echo "RECURSION: I am the root ... recursing all missing build targets NOW..."
echo "RECURSION: ...about to invoke: xcodebuild -configuration \"${CONFIGURATION}\" -project \"${PROJECT_NAME}.xcodeproj\" -target \"${TARGET_NAME}\" -sdk \"${OTHER_SDK_TO_BUILD}\" ${ACTION} RUN_CLANG_STATIC_ANALYZER=NO" BUILD_DIR=\"${BUILD_DIR}\" BUILD_ROOT=\"${BUILD_ROOT}\" SYMROOT=\"${SYMROOT}\"

xcodebuild -configuration "${CONFIGURATION}" -project "${PROJECT_NAME}.xcodeproj" -target "${TARGET_NAME}" -sdk "${OTHER_SDK_TO_BUILD}" ${ACTION} RUN_CLANG_STATIC_ANALYZER=NO BUILD_DIR="${BUILD_DIR}" BUILD_ROOT="${BUILD_ROOT}" SYMROOT="${SYMROOT}"

ACTION="build"

#Merge all platform binaries as a fat binary for each configurations.

# Calculate where the (multiple) built files are coming from:
CURRENTCONFIG_DEVICE_DIR=${SYMROOT}/${CONFIGURATION}-iphoneos
CURRENTCONFIG_SIMULATOR_DIR=${SYMROOT}/${CONFIGURATION}-iphonesimulator

echo "Taking device build from: ${CURRENTCONFIG_DEVICE_DIR}"
echo "Taking simulator build from: ${CURRENTCONFIG_SIMULATOR_DIR}"

CREATING_UNIVERSAL_DIR=${SYMROOT}/${CONFIGURATION}-universal
echo "...I will output a universal build to: ${CREATING_UNIVERSAL_DIR}"

# ... remove the products of previous runs of this script
#      NB: this directory is ONLY created by this script - it should be safe to delete!

rm -rf "${CREATING_UNIVERSAL_DIR}"
mkdir "${CREATING_UNIVERSAL_DIR}"

#
echo "lipo: for current configuration (${CONFIGURATION}) creating output file: ${CREATING_UNIVERSAL_DIR}/${EXECUTABLE_NAME}"
xcrun -sdk iphoneos lipo -create -output "${CREATING_UNIVERSAL_DIR}/${EXECUTABLE_NAME}" "${CURRENTCONFIG_DEVICE_DIR}/${EXECUTABLE_NAME}" "${CURRENTCONFIG_SIMULATOR_DIR}/${EXECUTABLE_NAME}"

#########
#
# Added: StackOverflow suggestion to also copy "include" files
#    (untested, but should work OK)
#
echo "Fetching headers from ${PUBLIC_HEADERS_FOLDER_PATH}"
echo "  (if you embed your library project in another project, you will need to add"
echo "   a "User Search Headers" build setting of: (NB INCLUDE THE DOUBLE QUOTES BELOW!)"
echo '        "$(TARGET_BUILD_DIR)/usr/local/include/"'
if [ -d "${CURRENTCONFIG_DEVICE_DIR}${PUBLIC_HEADERS_FOLDER_PATH}" ]
then
mkdir -p "${CREATING_UNIVERSAL_DIR}${PUBLIC_HEADERS_FOLDER_PATH}"
# * needs to be outside the double quotes?
cp -r "${CURRENTCONFIG_DEVICE_DIR}${PUBLIC_HEADERS_FOLDER_PATH}"* "${CREATING_UNIVERSAL_DIR}${PUBLIC_HEADERS_FOLDER_PATH}"
fi
fi

INSTALLER LES INSTRUCTIONS

  1. Créer un projet de bibliothèque statique
  2. Sélectionnez la cible
  3. Dans l'onglet "Build Settings", définissez "Build Active Architecture Only" sur "NO" (pour tous les éléments)
  4. Dans l'onglet "Build Phases", sélectionnez "Add ... New Build Phase ... New Run Script Build Phase"
  5. Copiez / collez le script (ci-dessus) dans la boîte

... BONUS OPTIONAL utilisation:

  1. FACULTATIF: si vous avez des en-têtes dans votre bibliothèque, ajoutez-les à la phase "Copier les en-têtes"
  2. FACULTATIF: ... et faites-les glisser de la section "Projet" vers la section "Public"
  3. FACULTATIF: ... et ils seront AUTOMATIQUEMENT exportés chaque fois que vous construirez l'application, dans un sous-répertoire du répertoire "debug-universal" (ils seront dans usr / local / include)
  4. FACULTATIF: REMARQUE: si vous essayez également de faire glisser / déposer votre projet dans un autre projet Xcode, cela expose un bogue dans Xcode 4, où il ne peut pas créer un fichier .IPA si vous avez des en-têtes publics dans votre projet glisser / déposer. Solution: n'intégrez pas de projets xcode (trop de bogues dans le code d'Apple!)

Si vous ne trouvez pas le fichier de sortie, voici une solution:

  1. Ajoutez le code suivant à la fin du script (avec la permission de Frederik Wallner): ouvrez "$ {CREATING_UNIVERSAL_DIR}"

  2. Apple supprime toutes les sorties après 200 lignes. Sélectionnez votre cible et dans la phase d'exécution du script, vous DEVEZ décocher: "Afficher les variables d'environnement dans le journal de génération"

  3. si vous utilisez un répertoire "build output" personnalisé pour XCode4, alors XCode place tous vos fichiers "inattendus" au mauvais endroit.

    1. Construire le projet
    2. Cliquez sur la dernière icône à droite, dans le coin supérieur gauche de Xcode4.
    3. Sélectionnez l'élément supérieur (il s'agit de votre "version la plus récente". Apple devrait le sélectionner automatiquement, mais ils n'y ont pas pensé)
    4. dans la fenêtre principale, faites défiler vers le bas. La toute dernière ligne doit se lire: lipo: pour la configuration actuelle (débogage), création du fichier de sortie: /Users/blah/Library/Developer/Xcode/DerivedData/AppName-ashwnbutvodmoleijzlncudsekyf/Build/Products/Debug-universal/libTargetName.a

    ... c'est l'emplacement de votre Universal Build.


Comment inclure des fichiers "non sourcecode" dans votre projet (PNG, PLIST, XML, etc.)

  1. Faites tout ce qui précède, vérifiez que cela fonctionne
  2. Créez une nouvelle phase d'exécution de script qui vient APRÈS LA PREMIÈRE (copiez / collez le code ci-dessous)
  3. Créer une nouvelle cible dans Xcode, de type "bundle"
  4. Dans votre MAIN PROJECT, dans "Build Phases", ajoutez le nouveau bundle comme quelque chose dont il "dépend" (section supérieure, appuyez sur le bouton plus, faites défiler vers le bas, trouvez le fichier ".bundle" dans vos produits)
  5. Dans votre NOUVELLE CIBLE BUNDLE, dans "Build Phases", ajoutez une section "Copy Bundle Resources", et glissez / déposez tous les fichiers PNG, etc.

Script pour copier automatiquement le ou les bundles intégrés dans le même dossier que votre bibliothèque statique FAT:

echo "RunScript2:"
echo "Autocopying any bundles into the 'universal' output folder created by RunScript1"
CREATING_UNIVERSAL_DIR=${SYMROOT}/${CONFIGURATION}-universal
cp -r "${BUILT_PRODUCTS_DIR}/"*.bundle "${CREATING_UNIVERSAL_DIR}"

2
Je l'ai utilisé sur quelques projets maintenant et j'ai expédié des trucs dans l'app-store qui les a utilisés pour construire les bibliothèques. Tout a fonctionné à 100%, donc je m'en tiens à cela pour l'instant (jusqu'à Xcode 4, peut-être)
Adam

2
Quelqu'un peut-il confirmer si cette méthode fonctionne pour XCode 4.5? J'essaie de compiler une bibliothèque statique et de l'utiliser dans mon projet principal. Je peux l'exécuter sur l'appareil mais pas sur le simulateur. Voici l'erreur que j'obtiens: il manque l'architecture i386 requise dans le fichier /Users/alex/Documents/iphone/production/iphone/mymedia/libMyUnrar4iOS.a (2 tranches)
Alex1987

2
Une idée comment faire fonctionner cela avec XCode 5 et ARM64? Si je laisse les architectures en standard, cela rend la bibliothèque avec armv7, armvs7 et i386 comme prévu. Si je mets des architectures à la norme, y compris 64 bits, la bibliothèque ne contient que "cputype 16777223". J'utilise otool -h sur le fichier .a pour vérifier ce qu'il y a à l'intérieur
Roger Binns

1
XCode5 a rendu l'ajout d'une phase de construction de script d'exécution encore plus délicat. consultez ceci: runscriptbuildphase.com
Fabio Napodano

1
Cela semble fonctionner correctement sur Xcode 6 sans changement (n'a essayé que quelques projets jusqu'à présent, et n'a pas encore soumis de mises à jour App Store, mais tout fonctionne bien jusqu'à présent).
Adam

85

J'ai passé de nombreuses heures à essayer de construire une grosse bibliothèque statique qui fonctionnera sur armv7, armv7s et le simulateur. Enfin trouvé une solution .

L'essentiel est de construire les deux bibliothèques (une pour le périphérique et une pour le simulateur) séparément, de les renommer pour les distinguer l'une de l'autre, puis de les lipo-créer dans une bibliothèque.

lipo -create libPhone.a libSimulator.a -output libUniversal.a

Je l'ai essayé et il fonctionne!


4
Je vous suggère de lire la réponse acceptée. Vous trouverez peut-être que cela a déjà été couvert, 2 ans auparavant ...
Adam

2
Je l'ai lu, j'ai utilisé le script, mais cela ne fonctionnait pas pour moi pour les armv7.
g_low

2
la commande lipo ne fonctionne pas sur le script, mais elle fonctionne très bien manuellement! 10x
Dima

9
+1 C'était vraiment tout ce dont j'avais besoin, pas un énorme script "make-a-framework".
LearnCocos2D

Votre SolutionURL renvoie «Erreur 404 - Introuvable»
Alex

74

J'ai créé un modèle de projet XCode 4 qui vous permet de créer un cadre universel aussi facilement que de créer une bibliothèque régulière.


Impossible de le construire avec la cible iOS 4.3. Obtenez l'erreur suivante: cible de déploiement non valide pour -stdlib = libc ++ (nécessite iOS 5.0 ou version ultérieure)
Alex1987

J'aimerais pouvoir donner plus de points de réputation pour cette réponse ... tellement plus facile que d'utiliser CMake pour créer une bibliothèque statique. Je te remercie tellement d'avoir fait cela!
iwasrobbed

Cela fonctionne aussi avec iOS 6 pour moi. Mais c'est peut-être parce que ma bibliothèque est assez simple et sans dépendances ni ressources
Paulius Vindzigelskis

Il y a un GRAND problème avec cette solution: d'autres qui veulent utiliser le framework créé par cette solution (cette solution suggère d'installer le modèle de travail en xcode) DOIVENT installer ce modèle sur LEUR xcode !!!
evya

Vous avez seulement besoin d'installer le modèle pour les cadres réels. Les faux frameworks fonctionneront bien dans Xcode non modifié.
Karl

30

Il existe un utilitaire de ligne de commande xcodebuildet vous pouvez exécuter la commande shell dans xcode. Donc, si cela ne vous dérange pas d'utiliser un script personnalisé, ce script peut vous aider.

#Configurations.
#This script designed for Mac OS X command-line, so does not use Xcode build variables.
#But you can use it freely if you want.

TARGET=sns
ACTION="clean build"
FILE_NAME=libsns.a

DEVICE=iphoneos3.2
SIMULATOR=iphonesimulator3.2






#Build for all platforms/configurations.

xcodebuild -configuration Debug -target ${TARGET} -sdk ${DEVICE} ${ACTION} RUN_CLANG_STATIC_ANALYZER=NO
xcodebuild -configuration Debug -target ${TARGET} -sdk ${SIMULATOR} ${ACTION} RUN_CLANG_STATIC_ANALYZER=NO
xcodebuild -configuration Release -target ${TARGET} -sdk ${DEVICE} ${ACTION} RUN_CLANG_STATIC_ANALYZER=NO
xcodebuild -configuration Release -target ${TARGET} -sdk ${SIMULATOR} ${ACTION} RUN_CLANG_STATIC_ANALYZER=NO







#Merge all platform binaries as a fat binary for each configurations.

DEBUG_DEVICE_DIR=${SYMROOT}/Debug-iphoneos
DEBUG_SIMULATOR_DIR=${SYMROOT}/Debug-iphonesimulator
DEBUG_UNIVERSAL_DIR=${SYMROOT}/Debug-universal

RELEASE_DEVICE_DIR=${SYMROOT}/Release-iphoneos
RELEASE_SIMULATOR_DIR=${SYMROOT}/Release-iphonesimulator
RELEASE_UNIVERSAL_DIR=${SYMROOT}/Release-universal

rm -rf "${DEBUG_UNIVERSAL_DIR}"
rm -rf "${RELEASE_UNIVERSAL_DIR}"
mkdir "${DEBUG_UNIVERSAL_DIR}"
mkdir "${RELEASE_UNIVERSAL_DIR}"

lipo -create -output "${DEBUG_UNIVERSAL_DIR}/${FILE_NAME}" "${DEBUG_DEVICE_DIR}/${FILE_NAME}" "${DEBUG_SIMULATOR_DIR}/${FILE_NAME}"
lipo -create -output "${RELEASE_UNIVERSAL_DIR}/${FILE_NAME}" "${RELEASE_DEVICE_DIR}/${FILE_NAME}" "${RELEASE_SIMULATOR_DIR}/${FILE_NAME}"

Peut-être semble inefficace (je ne suis pas bon en script shell), mais facile à comprendre. J'ai configuré une nouvelle cible exécutant uniquement ce script. Le script est conçu pour la ligne de commande mais n'est pas testé dans :)

Le concept de base est xcodebuildet lipo.

J'ai essayé de nombreuses configurations dans l'interface utilisateur de Xcode, mais rien n'a fonctionné. Comme il s'agit d'une sorte de traitement par lots, la conception en ligne de commande est plus adaptée, donc Apple a progressivement supprimé la fonctionnalité de génération par lots de Xcode. Je ne m'attends donc pas à ce qu'ils proposent à l'avenir une fonctionnalité de génération de lots basée sur l'interface utilisateur.


Merci, il est vraiment intéressant que les commandes simples sous-jacentes semblent toujours fonctionner - c'est juste qu'Apple a cassé leur interface graphique de manière spectaculaire. On dirait que je pourrais créer un modèle de projet entièrement personnalisé qui ne "sucerait" pas et ne résoudrait pas les choses cassées par Apple, en prédéfinissant toutes les cibles et en câblant ce script avec des vars de construction xcode. Je vais l'essayer sur mon prochain projet :)
Adam

1
J'ai utilisé un script similaire à celui-ci et l'ai placé sous une nouvelle cible contenant uniquement le script shell. Le script de construction récursif ci-dessus est très intelligent, mais inutilement déroutant.
benzado

1
Je préfère les scripts shell pour des trucs comme celui-ci, voici ma prise gist.github.com/3178578
slf

@benzado Oui, j'ai évité la complexité intentionnellement parce que je pense que le script shell doit être facile à lire pour être modifié.
Eonil

lipo: impossible d'ouvrir le fichier d'entrée: / Debug-iphoneos /
Dima

11

J'avais besoin d'une grosse bibliothèque statique pour JsonKit, j'ai donc créé un projet de bibliothèque statique dans Xcode, puis j'ai exécuté ce script bash dans le répertoire du projet. Tant que vous avez configuré le projet xcode avec "Build active configuration only" désactivé, vous devriez obtenir toutes les architectures dans une seule lib.

#!/bin/bash
xcodebuild -sdk iphoneos
xcodebuild -sdk iphonesimulator
lipo -create -output libJsonKit.a build/Release-iphoneos/libJsonKit.a build/Release-iphonesimulator/libJsonKit.a

7

Mise à jour IOS 10:

J'ai eu un problème avec la construction de la fatlib avec iphoneos10.0 car l'expression régulière dans le script n'attend que 9.x et moins et retourne 0.0 pour ios 10.0

pour résoudre ce problème, il suffit de remplacer

SDK_VERSION=$(echo ${SDK_NAME} | grep -o '.\{3\}$')

avec

SDK_VERSION=$(echo ${SDK_NAME} | grep -o '[\\.0-9]\{3,4\}$')

Merci. J'ai fait un changement similaire ce matin, mais j'ai utilisé \ d. Je pense que c'est celui que nous voulons (est-il meilleur ou pire que le vôtre?) ... grep -o '\ d \ {1,2 \} \. \ D \ {2 \} $'
Adam

Je pense que le mien est plus fiable car il ne prend en compte que les chiffres
ben

1
Non, la vôtre correspond à une façon particulière d'écrire des chiffres. Compte tenu de la prise en charge historique d'Apple (et de l'utilisation) des caractères et du texte raffinés (par exemple dans les noms de fichiers), je m'attendrais à ce que votre sélection exclusive de quelques chiffres soit moins fiable.
Adam

1
ok peut-être que vous avez raison. au moins le mien a également fait fonctionner mon projet et nous sommes en sécurité pour les prochaines 89 versions ios
ben

La solution @ben fonctionne pour moi, l'expression régulière d'Adam '[\\. 0-9] \ {3,4 \} $' donne le code d'erreur 2
Zee

4

J'ai transformé cela en un modèle Xcode 4 , dans la même veine que le modèle de cadre statique de Karl.

J'ai trouvé que la construction de frameworks statiques (au lieu de bibliothèques statiques simples) provoquait des plantages aléatoires avec LLVM, en raison d'un bug apparent de l'éditeur de liens - donc, je suppose que les bibliothèques statiques sont toujours utiles!


Salut Michael, j'ai essayé votre modèle de bibliothèque statique mais je peux compiler pour le simulateur mais pas pour le périphérique, voici l'erreur: ** BUILD FAILED ** Les commandes de build suivantes ont échoué: ProcessPCH / var / folder / qy / ncy6fkpn6677qt876ljrc54m0000gn / C / com .apple.Xcode.501 / SharedPrecompiledHeaders / MenuBarUniversal-Prefix-gwxxzpanxyudmfgryorafazokagi / MenuBarUniversal-Prefix.pch.pth MenuBarUniversal / MenuBarUniversal-Prefix.pch normal armv7 objective-c com.apple.compilers.ll0.1v.1cl (1) ) Affichage des 200 premiers avis uniquement La commande / bin / sh a échoué avec le code de sortie 65
Kappe

2

Bon travail! J'ai piraté ensemble quelque chose de similaire, mais j'ai dû l'exécuter séparément. Le faire simplement partie du processus de construction le rend tellement plus simple.

Un élément à noter. J'ai remarqué qu'il ne copie aucun des fichiers d'inclusion que vous marquez comme publics. J'ai adapté ce que j'avais dans mon script au vôtre et cela fonctionne assez bien. Collez ce qui suit à la fin de votre script.

if [ -d "${CURRENTCONFIG_DEVICE_DIR}/usr/local/include" ]
then
  mkdir -p "${CURRENTCONFIG_UNIVERSAL_DIR}/usr/local/include"
  cp "${CURRENTCONFIG_DEVICE_DIR}"/usr/local/include/* "${CURRENTCONFIG_UNIVERSAL_DIR}/usr/local/include"
fi

1
OK, j'ai ajouté cela à la réponse ci-dessus. (je n'ai pas encore eu l'occasion de le tester, mais il me semble correct)
Adam

1

En fait, je viens d' écrire mon propre script à cet effet. Il n'utilise pas Xcode. (Il est basé sur un script similaire dans le projet Gambit Scheme.)

Fondamentalement, il exécute ./configure et fait trois fois (pour i386, armv7 et armv7s), et combine chacune des bibliothèques résultantes dans une librairie grasse.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.