emcc - Online în cloud

PROGRAM:

NUME

emcc - Interfața compilatorului Emscripten

DESCRIERE

fișier emcc [opțiuni]...

pod normală. gcc/g++ Opțiuni voi muncă, pentru exemplu:
--Ajutor Afișați aceste informații

--versiune
Afișează informații despre versiunea compilatorului

Opţiuni acea sunt modificată or nou in emcc includ:
-O0 Fără optimizări (implicit)

-O1 Optimizări simple, inclusiv asm.js, LLVM -O1 optimizări și fără timp de rulare
afirmații sau capturarea excepțiilor C++ (pentru a reactiva capturarea excepțiilor C++, utilizați -s
DISABLE_EXCEPTION_CATCHING=0). (Pentru detalii despre efectele diferitelor opt
niveluri, consultați apply_opt_level() în tools/shared.py și, de asemenea, src/settings.js.) Notă:
Optimizările se fac numai la compilarea în JavaScript, nu la intermediar
cod biți, *cu excepția cazului în care* construiți cu EMCC_OPTIMIZE_NORMALLY=1 (nu este recomandat decât dacă
stii ce faci!)

-O2 As -O1, plus relooper (recrearea buclei), LLVM -O2 optimizări și

-s ALIASING_FUNCTION_POINTERS=1

-O3 As -O2, plus optimizări periculoase care pot rupe codul generat! Aceasta adaugă

-s FORCE_ALIGNED_MEMORY=1 -s DOUBLE_MODE=0 -s PRECISE_I64_MATH=0 --închidere 1
--llvm-lto 1

Acest lucru nu este deloc recomandat. O idee mai bună este să încercați fiecare dintre acestea separat
partea de sus a -O2 sa vezi ce functioneaza. Consultați wiki și src/settings.js (pentru -s opțiuni)
pentru mai multe informatii.

-s OPȚIUNE=VALOARE
Opțiunea de generare a codului JavaScript a fost transmisă în compilatorul emscripten. Pentru
opțiunile disponibile, consultați src/settings.js Rețineți că pentru opțiunile care sunt liste, dvs
au nevoie de ghilimele în majoritatea shell-urilor, de exemplu

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

or

-s „RUNTIME_LINKED_LIBS=['liblib.so']”

(fără „-urile externe din oricare dintre acestea, veți primi o eroare)

De asemenea, puteți specifica un fișier din care ar fi citită valoarea, de exemplu,

-s DEAD_FUNCTIONS=@/path/to/file

Conținutul /cale/la/fișier va fi citit, JSON.parsed și setat în DEAD_FUNCTIONS
(deci fișierul ar putea conține

["_func1", "func2"]

). Rețineți că calea trebuie să fie absolută, nu relativă.

-g Utilizați informațiile de depanare. Rețineți că aveți nevoie de acest lucru în ultima fază de compilare de la
cod de biți în JavaScript, altfel îl vom elimina implicit în -O1 Si mai sus. În
-O0, numerele de linii vor fi afișate în codul generat. În -O1 iar mai sus, cel
Optimizer elimină aceste comentarii. Acest steag are totuși ca efect
dezactivarea oricărui lucru care provoacă alterarea sau diminuarea numelui (închiderea sau
trece de înregistrare).

--typed-arrays
0: Fără matrice tipizate 1: Matrice tipizate paralel 2: Matrice tipizată partajată (ca C)
(Implicit)

--llvm-opts
0: Fără optimizări LLVM (implicit în -O0) 1: -O1 Optimizări LLVM (implicit în
-O1) 2: -O2 Optimizări LLVM 3: -O3 Optimizări LLVM (implicit în -O2+)

--llvm-lto
0: Fără LTO LLVM (implicit în -O2 și mai jos) 1: LLVM LTO (implicit în -O3) Notă: Dacă
Optimizările LLVM nu sunt executate (vezi --llvm-opts), setarea la 1 nu are efect.

--închidere
0: Nici un compilator de închidere (implicit în -O2 și mai jos) 1: Rulați compilatorul de închidere. Acest
reduce foarte mult dimensiunea codului și, în unele cazuri, poate crește viteza de rulare (deși
se poate întâmpla şi invers). Rețineți că este nevoie de timp pentru a rula și poate necesita ceva
modificări ale codului. Acesta este rulat implicit în -O3.

În modul asm.js, închiderea va fi folosită numai pe codul „shell” din jurul compilatului
cod (codul compilat va fi procesat de minificatorul personalizat asm.js).

Notă: dacă compilatorul de închidere atinge o memorie lipsită, încercați să ajustați JAVA_HEAP_SIZE în
mediul (de exemplu, la 4096m pentru 4GB).

--js-transform
va fi apelat pe codul generat înainte de a fi optimizat. Acest lucru vă permite
modificați JavaScript, de exemplu adăugarea unui cod sau eliminarea unui cod, într-un fel
că acele modificări vor fi optimizate împreună cu codul generat
în mod corespunzător. va fi apelat cu numele de fișier al codului generat ca a
parametru; pentru a modifica codul, puteți citi datele originale și apoi le puteți atașa
sau suprascrieți-l cu datele modificate. este interpretat ca un spațiu separat
lista de argumente, de exemplu, de „python processor.py” va provoca un python
scriptul care urmează să fie rulat.

--pre-js
Un fișier al cărui conținut este adăugat înaintea codului generat. Acest lucru se face *inainte*
optimizare, deci va fi minimizat corect dacă se rulează compilatorul de închidere.

--post-js
Un fișier al cărui conținut este adăugat după codul generat. Acest lucru se face *înainte*
optimizare, deci va fi minimizat corect dacă se rulează compilatorul de închidere.

--încorporați-fișier
Un fișier de încorporat în JavaScript generat. Codul compilat va putea
accesați fișierul din directorul curent cu același nume ca și aici. Astfel, dacă
tu faci --încorporați-fișier dir/file.dat, apoi (1) dir/file.dat trebuie să existe relativ la
unde rulați emcc și (2) codul dvs. compilat va putea găsi fișierul prin
citind aceeași cale, dir/file.dat. Dacă un director este transmis aici, este întreg
conținutul va fi încorporat.

--preload-file
Un fișier de preîncărcat înainte de a rula codul compilat în mod asincron. In caz contrar
similar --încorporați-fișier, cu excepția faptului că această opțiune este relevantă numai la generare
HTML (folosește XHR binar asincron) sau JS care va fi folosit într-o pagină web. Dacă
un director este transmis aici, întregul său conținut va fi preîncărcat. Fișiere preîncărcate
sunt stocate în filename.data, unde filename.html este fișierul principal pe care îl compilați
la. Pentru a rula codul, veți avea nevoie atât de .html, cât și de .data.

emcc rulează tools/file_packager.py pentru a face ambalarea efectivă a embedded și
fișiere preîncărcate. Puteți rula singur pachetul de fișiere, dacă doriți, consultați documentele
în interiorul acelui dosar. Apoi ar trebui să puneți rezultatul pachetului de fișiere într-un emcc
--pre-js, astfel încât să se execute înainte de codul dvs. compilat principal (sau să îl rulați înainte în
într-un alt mod).

--comprimare
Comprimați atât codul compilat, cât și fișierele încorporate/preîncărcate. ar trebui să fie o
triplu,

, ,

unde native_encoder este un executabil nativ care comprimă stdin în stdout (the
cea mai simplă interfață posibilă), js_decoder este un fișier JavaScript care implementează a
decodor, iar js_name este numele funcției de apelat în fișierul decodor (care
ar trebui să primească o matrice/matrice tipată și să returneze o matrice/matrice tipizată. Comprimare
funcționează numai atunci când se generează HTML. Când compresia este activată, toate fișierele specificate să fie
preîncărcate sunt comprimate într-o arhivă mare, care are același nume ca și
HTML de ieșire, dar cu sufixul .data.compress

--minimizează
0: Nu reduceți spațiul alb JavaScript generat (implicit în -O0, -O1, sau daca
-g este folosit)

1: Minimizează JavaScript-urile generate

spații albe (implicit în -O2+, presupunând -g nu este folosit)

--Despică
Împarte fișierul javascript rezultat în bucăți pentru a ușura depanarea. Această opțiune
funcționează numai dacă este generat Javascript (țintă -o .js). Fișiere cu funcție
declarațiile trebuie să fie încărcate înainte de fișierul principal la execuție.

Fără opțiunea „-g”:

Creează fișiere cu declarații de funcție până la dimensiunea dată cu sufixul
„_functions.partxxx.js” și un fișier principal cu sufixul „.js”.

Cu opțiunea „-g”:

Recreează structura de directoare a fișierelor sursă C și funcția de stocare
declarații în fișierele C respective cu sufixul „.js”. Dacă un astfel de dosar
depășește dimensiunea dată, sunt create fișiere cu sufixul „.partxxx.js”. Principalul
fișierul se află în directorul de bază și are sufixul „.js”.

--lega Compilează codul sursă utilizând abordarea de legături „embind”, care conectează C/C++
și JS.

--ignore-linking-dinamic În mod normal, emcc va trata legătura dinamică ca
legarea statică, prin legarea în codul din biblioteca dinamică. Acest lucru eșuează dacă
aceeași bibliotecă dinamică este conectată de mai multe ori. Cu această opțiune, legătura dinamică
este ignorat, ceea ce permite sistemului de construire să continue fără erori. Totuși, tu
va trebui să vă conectați manual la bibliotecile partajate mai târziu.

--shell-file
Numele căii către un fișier HTML schelet utilizat la generarea rezultatelor HTML. Cochilia
fișierul folosit trebuie să aibă în interior acest simbol: {{{ SCRIPT_CODE }}} Rețineți că acesta
argumentul este ignorat dacă o altă destinație decât HTML este specificată folosind -o opțiune.

--js-library
O bibliotecă JavaScript de folosit în plus față de cele din src/library_* Emscripten

-v Activează ieșirea verbosă. Aceasta va trece -v la Clang și, de asemenea, activați EMCC_DEBUG
detaliază operațiunile emcc

--jcache
Utilizați un cache JavaScript. Aceasta este dezactivată în mod implicit. Când este activat, emcc va stoca
rezultatele compilarii într-un cache și verificați cache-ul atunci când compilați mai târziu,
ceva ca ceea ce face ccache. Acest lucru permite versiuni incrementale - unde vă aflați
compilarea unui program mare, dar modificat doar o mică parte din el - pentru a fi mult mai rapid
(cu costul a mai multor IO pe disc pentru accesele în cache). Rețineți că trebuie să activați
--jcache atât pentru încărcarea, cât și pentru salvarea datelor, așa că trebuie să le activați pe o versiune completă
pentru ca o construcție incrementală ulterioară (unde o activați) să fie accelerată.

Memorarea în cache funcționează separat pe 4 părți ale compilației: „pre”, care este tipuri și global
variabile; acele informații sunt apoi introduse în „funcții”, care sunt funcțiile (care
paralelizăm), și apoi „post” care adaugă informații finale bazate pe
funcții (de exemplu, avem nevoie de codul de asistență long64). În cele din urmă, „jsfuncs” sunt
Optimizări la nivel de JavaScript. Fiecare dintre cele 4 părți poate fi stocată în cache separat, dar
rețineți că acestea se pot afecta reciproc: Dacă recompilați un singur fișier C++, acesta
modifică o variabilă globală - de exemplu, adaugă, elimină sau modifică o variabilă globală, de exemplu
prin adăugarea unui printf sau prin adăugarea unui timestamp la timp de compilare, atunci „pre” nu poate fi
încărcat din cache. Și din moment ce „ieșirea lui pre este trimisă la „funcs” și „post”, ei
va fi de asemenea invalidat și numai „jsfuncs” va fi stocat în cache. Așa că evitați modificarea
globals pentru a permite stocarea în cache să funcționeze pe deplin.

Pentru a rezolva problema menționată în paragraful anterior, puteți utiliza

emscripten_jcache_printf

când adăugați debug printfs la codul dvs. Această funcție este special preprocesată astfel
că nu creează un șir constant global pentru primul său argument. Vedea
emscripten.h pentru mai multe detalii. Rețineți în special că trebuie să aveți deja un
apelați la acea funcție din codul dvs. * înainte de * să adăugați una și să faceți un incremental
build, astfel încât adăugarea unei referințe externe (de asemenea, o proprietate globală) nu
invalidează totul.

Rețineți că ar trebui să utilizați -g în timpul etapei de conectare (bitcode la JS), pentru jcache la
funcționează (în caz contrar, minificarea JS îl poate încurca).

--clear-cache
Șterge manual memoria cache a bibliotecilor de sistem emscripten compilate (libc++,
libc++abi, libc). Acest lucru este în mod normal gestionat automat, dar dacă actualizați llvm
în loc (în loc să aibă un director diferit pentru o versiune nouă), stocarea în cache
mecanismul poate deveni confuz. Golirea memoriei cache poate rezolva probleme ciudate legate de
incompatibilități de cache, cum ar fi zgomotul care nu se conectează cu fișierele din bibliotecă. Acesta de asemenea
șterge alte date din cache, cum ar fi jcache-ul și relooperul bootstrapped. După
memoria cache este șters, acest proces se va închide.

--save-bc PATH
Când compilați în JavaScript sau HTML, această opțiune va salva o copie a codului de biți
la calea specificată. Codul de biți va include toate fișierele care sunt legate, inclusiv
biblioteci standard și după orice optimizare a timpului de legătură (dacă există).

--memory-init-file
Dacă este activat, generăm un fișier separat de inițializare a memoriei. Acest lucru este mai eficient
decât stocarea datelor de inițializare a memoriei încorporate în JavaScript ca text.
(implicit este dezactivat)

Fișierul țintă, dacă este specificat (-o ), definește ce va fi generat:

.js
JavaScript

.html
HTML cu JavaScript încorporat

.bc
Cod de biți LLVM (implicit)

.o
Cod de biți LLVM (la fel ca .bc)

(Rețineți că dacă --memory-init-file este folosit, apoi pe lângă un fișier .js sau .html care este
generat, va apărea și un fișier .mem.)

-c opțiunea (care îi spune gcc să nu ruleze linker-ul) va face ca codul de biți LLVM să fie
generat, deoarece emcc generează JavaScript numai în etapa finală de conectare a construirii.

Fișierele de intrare pot fi fie fișiere de cod sursă pe care Clang le poate gestiona (C sau C++), LLVM
cod de biți în formă binară sau fișiere de asamblare LLVM în formă care poate fi citită de om.

emcc este afectat de mai multe variabile de mediu. Pentru detalii, vedeți sursa emcc
(căutați „os.environ”).

emcc: ținte acceptate: cod de bit llvm, javascript, NU elf (autoconf îi place să vadă elf
de mai sus pentru a activa suportul pentru obiecte partajate)

DREPTURI DE AUTOR

Copyright © 2013 autorii Emscripten (vezi AUTHORS.txt) Acesta este gratuit și open source
software sub licența MIT. NU există garanție; nici măcar pentru VANTABILITATE sau
ADEVĂRUL PENTRU UN SCOP PARTICULAR.

Utilizați emcc online folosind serviciile onworks.net