emcc - En ligne dans le Cloud

PROGRAMME:

Nom

emcc - interface du compilateur Emscripten

DESCRIPTION

fichier emcc [options]...

pont Ordinaire gcc/g++ Options sera travailler, en Exemple:
--Aidez-moi Afficher ces informations

--version
Afficher les informations sur la version du compilateur

Options qui modifié or neufs in emcc consistent à
-O0 Aucune optimisation (par défaut)

-O1 Optimisations simples, y compris asm.js, LLVM -O1 optimisations et pas d'exécution
assertions ou capture d'exception C++ (pour réactiver la capture d'exception C++, utilisez -s
DISABLE_EXCEPTION_CATCHING=0 ). (Pour plus de détails sur les effets des différents opt
niveaux, voir apply_opt_level() dans tools/shared.py et aussi src/settings.js.) Remarque :
Les optimisations ne sont effectuées que lors de la compilation en JavaScript, pas pour l'intermédiaire
bitcode, *à moins que* vous construisiez avec EMCC_OPTIMIZE_NORMALLY=1 (non recommandé sauf si
Tu sais ce que tu fais!)

-O2 As -O1, plus le relooper (recréation de boucle), LLVM -O2 optimisations, et

-s ALIASING_FUNCTION_POINTERS=1

-O3 As -O2, ainsi que des optimisations dangereuses qui peuvent casser le code généré ! Cela ajoute

-s FORCE_ALIGNED_MEMORY=1 -s DOUBLE_MODE=0 -s PRECISE_I64_MATH=0 --fermeture 1
--llvm-lto 1

Ce n'est pas du tout recommandé. Une meilleure idée est d'essayer chacun d'eux séparément sur
haut de -O2 pour voir ce qui fonctionne. Voir le wiki et src/settings.js (pour le -s options)
pour plus d'information.

-s OPTION=VALEUR
Option de génération de code JavaScript transmise au compilateur emscripten. Pour le
options disponibles, voir src/settings.js Notez que pour les options qui sont des listes, vous
besoin de guillemets dans la plupart des shells, par exemple

-s RUNTIME_LINKED_LIBS="['liblib.so']"

or

-s "RUNTIME_LINKED_LIBS=['liblib.so']"

(sans le "s" externe dans l'un ou l'autre, vous auriez une erreur)

Vous pouvez également spécifier un fichier à partir duquel la valeur serait lue, par exemple,

-s DEAD_FUNCTIONS=@/chemin/vers/fichier

Le contenu de /chemin/vers/fichier sera lu, JSON.parsed et défini dans DEAD_FUNCTIONS
(donc le fichier peut contenir

["_func1", "func2"]

). Notez que le chemin doit être absolu et non relatif.

-g Utilisez les informations de débogage. Notez que vous en aurez besoin lors de la dernière phase de compilation de
bitcode en JavaScript, sinon nous le supprimerons par défaut dans -O1 et ci-dessus. Dans
-O0, les numéros de ligne seront affichés dans le code généré. Dans -O1 et au-dessus, le
optimiseur supprime ces commentaires. Ce drapeau a cependant pour effet de
désactiver tout ce qui provoque la mutilation ou la minification du nom (fermeture ou
enregistrer le laissez-passer).

--typed-tableaux
0 : aucun tableau typé 1 : tableaux typés parallèles 2 : tableaux typés partagés (de type C)
(Par défaut)

--llvm-opts
0 : aucune optimisation LLVM (par défaut dans -O0) 1: -O1 Optimisations LLVM (par défaut dans
-O1) 2: -O2 Optimisations LLVM 3 : -O3 Optimisations LLVM (par défaut dans -O2+)

--llvm-lto
0 : pas de LLVM LTO (par défaut dans -O2 et ci-dessous) 1 : LLVM LTO (par défaut dans -O3) Remarque : si
Les optimisations LLVM ne sont pas exécutées (voir --llvm-opts), le définir sur 1 n'a aucun effet.

--fermeture
0 : aucun compilateur de fermeture (par défaut dans -O2 et ci-dessous) 1 : Exécutez le compilateur de fermeture. Cette
réduit considérablement la taille du code et peut dans certains cas augmenter la vitesse d'exécution (bien que
l'inverse peut également se produire). Notez que son exécution prend du temps et peut nécessiter quelques
modifications apportées au code. Ceci est exécuté par défaut dans -O3.

En mode asm.js, la fermeture ne sera utilisée que sur le code 'shell' autour du compilé
code (le code compilé sera traité par le minificateur personnalisé asm.js).

Remarque : si le compilateur de fermeture rencontre un manque de mémoire, essayez d'ajuster JAVA_HEAP_SIZE dans
l'environnement (par exemple, à 4096 m pour 4 Go).

--js-transformer
sera appelé sur le code généré avant qu'il ne soit optimisé. Cela vous permet
modifier le JavaScript, par exemple en ajoutant du code ou en supprimant du code, d'une manière
que ces modifications seront optimisées avec le code généré
correctement. sera appelé avec le nom de fichier du code généré comme
paramètre; pour modifier le code, vous pouvez lire les données d'origine puis les ajouter
ou l'écraser avec les données modifiées. est interprété comme un espace séparé
liste d'arguments, par exemple, de "python processor.py" provoquera un python
script à exécuter.

--pre-js
Un fichier dont le contenu est ajouté avant le code généré. C'est fait *avant*
optimisation, il sera donc minifié correctement si le compilateur de fermeture est exécuté.

--post-js
Un fichier dont le contenu est ajouté après le code généré Ceci est fait *avant*
optimisation, il sera donc minifié correctement si le compilateur de fermeture est exécuté.

--embed-fichier
Un fichier à intégrer dans le JavaScript généré. Le code compilé pourra
accéder au fichier dans le répertoire courant avec le même nom que celui donné ici. Donc si
tu fais --embed-fichier dir/file.dat, alors (1) dir/file.dat doit exister par rapport à
où vous exécutez emcc, et (2) votre code compilé pourra trouver le fichier en
lire ce même chemin, dir/file.dat. Si un répertoire est passé ici, sa totalité
le contenu sera intégré.

--preload-fichier
Un fichier à précharger avant d'exécuter le code compilé de manière asynchrone. Autrement
similaire à --embed-fichier, sauf que cette option n'est pertinente que lors de la génération
HTML (il utilise des XHR binaires asynchrones), ou JS qui sera utilisé dans une page Web. Si
un répertoire est passé ici, tout son contenu sera préchargé. Fichiers préchargés
sont stockés dans filename.data, où filename.html est le fichier principal que vous compilez
à. Pour exécuter votre code, vous aurez besoin à la fois du .html et du .data.

emcc exécute tools/file_packager.py pour faire l'empaquetage réel des
fichiers préchargés. Vous pouvez exécuter le packager de fichiers vous-même si vous le souhaitez, voir la documentation
à l'intérieur de ce fichier. Vous devez ensuite mettre la sortie du packager de fichiers dans un emcc
--pre-js, afin qu'il s'exécute avant votre code compilé principal (ou exécutez-le avant dans
d'une autre manière).

--compression
Compressez à la fois le code compilé et les fichiers intégrés/préchargés. devrait être un
tripler,

, ,

où native_encoder est un exécutable natif qui compresse stdin en stdout (le
interface la plus simple possible), js_decoder est un fichier JavaScript qui implémente un
décodeur, et js_name est le nom de la fonction à appeler dans le fichier décodeur (qui
devrait recevoir un tableau/tableau typé et renvoyer un tableau/tableau typé. Compression
ne fonctionne que lors de la génération HTML. Lorsque la compression est activée, tous les fichiers spécifiés pour être
préchargés sont compressés dans une grande archive, qui porte le même nom que le
sortie HTML mais avec le suffixe .data.compress

--minifier
0 : Ne pas réduire l'espace blanc du JavaScript généré (par défaut dans -O0, -O1, ou si
-g est utilisé)

1 : minifier les JavaScript générés

espace (par défaut dans -O2+, en supposant -g N'est pas utilisé)

--diviser
Divise le fichier javascript résultant en morceaux pour faciliter le débogage. Cette option
ne fonctionne que si Javascript est généré (cible -o .js). Fichiers avec fonction
les déclarations doivent être chargées avant le fichier principal lors de l'exécution.

Sans l'option "-g":

Crée des fichiers avec des déclarations de fonction jusqu'à la taille donnée avec le suffixe
"_functions.partxxx.js" et un fichier principal avec le suffixe ".js".

Avec l'option "-g":

Recrée la structure de répertoires des fichiers source C et stocke la fonction
déclarations dans leurs fichiers C respectifs avec le suffixe ".js". Si un tel fichier
dépasse la taille donnée, des fichiers avec le suffixe ".partxxx.js" sont créés. Le principal
réside dans le répertoire de base et a le suffixe ".js".

--lier Compile le code source à l'aide de l'approche des liaisons « embind », qui connecte C/C++
et JS.

--ignore-liaison-dynamique Normalement, emcc traitera les liens dynamiques comme
liaison statique, en liant dans le code de la bibliothèque dynamique. Cela échoue si le
la même bibliothèque dynamique est liée plus d'une fois. Avec cette option, la liaison dynamique
est ignoré, ce qui permet au système de construction de continuer sans erreur. Cependant, vous
devrez vous connecter manuellement aux bibliothèques partagées plus tard.

--shell-fichier
Le nom du chemin d'accès à un fichier HTML squelette utilisé lors de la génération de la sortie HTML. La coquille
Le fichier utilisé doit contenir ce jeton : {{{ SCRIPT_CODE }}} Notez que ce
l'argument est ignoré si une cible autre que HTML est spécifiée à l'aide de la -o option.

--js-bibliothèque
Une bibliothèque JavaScript à utiliser en plus de celles du src/library_* d'Emscripten

-v Active la sortie détaillée. Cela va passer -v à Clang, et permet également à EMCC_DEBUG de
détaille les opérations d'emcc

--jcache
Utilisez un cache JavaScript. Ceci est désactivé par défaut. Lorsqu'il est activé, emcc stockera
les résultats de la compilation dans un cache et vérifier le cache lors de la compilation ultérieure,
quelque chose comme ce que fait ccache. Cela permet des builds incrémentiels - où que vous soyez
compiler un gros programme mais n'en modifier qu'une petite partie - pour être beaucoup plus rapide
(au prix de plus d'E/S disque pour les accès au cache). Notez que vous devez activer
--jcache pour le chargement et la sauvegarde des données, vous devez donc l'activer sur une version complète
pour qu'une version incrémentielle ultérieure (où vous l'activez également) soit accélérée.

La mise en cache fonctionne séparément sur 4 parties de la compilation : 'pre' qui est les types et global
variables; cette information est ensuite introduite dans des « fonctions », qui sont les fonctions (qui
nous parallélisons), puis 'post' qui ajoute des informations finales basées sur le
fonctions (par exemple, avons-nous besoin du code de support long64). Enfin, les 'jsfuncs' sont
Optimisations au niveau JavaScript. Chacune des 4 parties peut être mise en cache séparément, mais
notez qu'ils peuvent s'affecter : si vous recompilez un seul fichier C++ qui
change une variable globale - par exemple, ajoute, supprime ou modifie une variable globale, disons
en ajoutant un printf ou en ajoutant un horodatage à la compilation, alors 'pre' ne peut pas être
chargé depuis le cache. Et comme la sortie de 'pre' est envoyée à 'funcs' et 'post', ils
sera également invalidé et seul 'jsfuncs' sera mis en cache. Donc évitez de modifier
globals pour permettre à la mise en cache de fonctionner pleinement.

Pour contourner le problème évoqué dans le paragraphe précédent, vous pouvez utiliser

emscripten_jcache_printf

lors de l'ajout de printfs de débogage à votre code. Cette fonction est spécialement prétraitée pour
qu'il ne crée pas de chaîne constante globale pour son premier argument. Voir
emscripten.h pour plus de détails. Notez en particulier que vous devez déjà avoir un
appelez cette fonction dans votre code *avant* d'en ajouter une et de faire un incrémentiel
build, de sorte que l'ajout d'une référence externe (également une propriété globale) ne
tout invalider.

Notez que vous devez utiliser -g lors de l'étape de liaison (bitcode vers JS), pour que jcache vers
travail (sinon, la minification JS peut le confondre).

--vider le cache
Efface manuellement le cache des bibliothèques système emscripten compilées (libc++,
libc++abi, libc). Ceci est normalement géré automatiquement, mais si vous mettez à jour llvm
sur place (au lieu d'avoir un répertoire différent pour une nouvelle version), la mise en cache
mécanisme peut se confondre. Vider le cache peut résoudre des problèmes étranges liés à
incompatibilités de cache, comme clang qui ne parvient pas à se lier aux fichiers de la bibliothèque. Ça aussi
efface les autres données mises en cache comme le jcache et le relooper bootstrap. Après le
le cache est vidé, ce processus se terminera.

--save-bc PATH
Lors de la compilation en JavaScript ou HTML, cette option enregistrera une copie du bitcode
au chemin spécifié. Le bitcode inclura tous les fichiers liés, y compris
bibliothèques standard, et après toute optimisation du temps de liaison (le cas échéant).

--fichier-init-mémoire
Si cette option est activée, nous générons un fichier d'initialisation de mémoire séparé. C'est plus efficace
que de stocker les données d'initialisation de la mémoire intégrées dans JavaScript sous forme de texte.
(la valeur par défaut est désactivée)

Le fichier cible, s'il est spécifié (-o ), définit ce qui sera généré :

.js
JavaScript

.html
HTML avec JavaScript intégré

.avant JC
Bitcode LLVM (par défaut)

.o
Bitcode LLVM (identique à .bc)

(Notez que si --fichier-init-mémoire est utilisé, puis en plus d'un fichier .js ou .html qui est
généré, un fichier .mem apparaîtra également.)

La -c (qui indique à gcc de ne pas exécuter l'éditeur de liens) entraînera l'apparition du bitcode LLVM
généré, car emcc ne génère du JavaScript que dans la dernière étape de la création de liens.

Le ou les fichiers d'entrée peuvent être des fichiers de code source que Clang peut gérer (C ou C++), LLVM
bitcode sous forme binaire ou fichiers d'assemblage LLVM sous forme lisible par l'homme.

emcc est affecté par plusieurs variables d'environnement. Pour plus de détails, consultez la source d'emcc
(recherchez 'os.environ').

emcc : cibles prises en charge : llvm bitcode, javascript, PAS elf (autoconf aime voir elf
ci-dessus pour activer la prise en charge des objets partagés)

DROIT D'AUTEUR

Copyright © 2013 les auteurs Emscripten (voir AUTHORS.txt) Ceci est gratuit et open source
logiciel sous licence MIT. Il n'y a AUCUNE garantie ; même pas pour la COMMERCIALISATION ou
APTITUDE A UN USAGE PARTICULIER.

Utiliser emcc en ligne à l'aide des services onworks.net