emcc - Online in de cloud

PROGRAMMA:

NAAM

emcc - Emscripten-compiler-frontend

PRODUCTBESCHRIJVING

emcc [opties] bestand...

De meeste een gcc/g++ opties wil werken, For voorbeeld:
--help Geef deze informatie weer

--versie
Informatie over de versie van de compiler weergeven

Opties dat zijn gewijzigd or nieuwe in emcc omvatten:
-O0 Geen optimalisaties (standaard)

-O1 Eenvoudige optimalisaties, waaronder asm.js, LLVM -O1 optimalisaties en geen runtime
beweringen of het afvangen van C++-uitzonderingen (om het afvangen van C++-uitzonderingen weer in te schakelen, gebruikt u -s
DISABLE_EXCEPTION_CATCHING=0). (Voor meer informatie over de effecten van verschillende opt
niveaus, zie apply_opt_level() in tools/shared.py en ook src/settings.js.) Opmerking:
Optimalisaties worden alleen gedaan bij het compileren naar JavaScript, niet naar intermediate
bitcode, *tenzij* u bouwt met EMCC_OPTIMIZE_NORMALLY=1 (niet aanbevolen tenzij
je weet wat je doet!)

-O2 As -O1, plus de relooper (loop recreatie), LLVM -O2 optimalisaties, en

-s ALIASING_FUNCTION_POINTERS=1

-O3 As -O2, plus gevaarlijke optimalisaties die de gegenereerde code kunnen breken! Dit voegt toe

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

Dit wordt helemaal niet aanbevolen. Een beter idee is om elk van deze afzonderlijk te proberen
boven -O2 om te zien wat werkt. Zie de wiki en src/settings.js (voor de -s opties)
voor meer informatie.

-s OPTIE=WAARDE
Optie voor het genereren van JavaScript-code doorgegeven aan de emscripten-compiler. Voor de
beschikbare opties, zie src/settings.js Merk op dat voor opties die lijsten zijn, jij
hebben bijvoorbeeld aanhalingstekens nodig in de meeste shells

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

or

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

(zonder de externe "s in een van beide zou u een foutmelding krijgen)

U kunt ook een bestand opgeven waaruit de waarde moet worden gelezen, bijvoorbeeld

-s DEAD_FUNCTIONS=@/pad/naar/bestand

De inhoud van /pad/naar/bestand wordt gelezen, JSON.parsed en ingesteld in DEAD_FUNCTIONS
(zodat het bestand kan bevatten

["_func1", "func2"]

). Merk op dat het pad absoluut moet zijn, niet relatief.

-g Gebruik foutopsporingsinformatie. Merk op dat je deze tijdens de laatste compilatiefase nodig hebt
bitcode naar JavaScript, anders verwijderen we het standaard in -O1 en hoger. In
-O0, worden regelnummers weergegeven in de gegenereerde code. In -O1 en hoger, de
optimizer verwijdert die opmerkingen. Deze vlag heeft echter wel het effect van
alles uitschakelen dat naamverminking of minificatie veroorzaakt (sluiting of de
pas registreren).

--getypte-arrays
0: Geen getypeerde arrays 1: Parallel getypeerde arrays 2: Gedeelde (C-achtige) getypeerde arrays
(Standaard)

--llvm-opt
0: geen LLVM-optimalisaties (standaard in -O0) 1: -O1 LLVM-optimalisaties (standaard in
-O1) 2: -O2 LLVM optimalisaties 3: -O3 LLVM-optimalisaties (standaard in -O2+)

--llvm-lto
0: Geen LLVM LTO (standaard in -O2 en lager) 1: LLVM LTO (standaard in -O3) Opmerking: Als
LLVM-optimalisaties worden niet uitgevoerd (zie --llvm-opt), heeft het instellen op 1 geen effect.

--sluiting
0: geen sluitcompiler (standaard in -O2 en hieronder) 1: Voer de compiler voor sluiting uit. Dit
vermindert de codegrootte aanzienlijk en kan in sommige gevallen de runtime-snelheid verhogen (hoewel
het tegenovergestelde kan ook voorkomen). Houd er rekening mee dat het tijd kost om te werken, en mogelijk wat tijd nodig heeft
wijzigingen in de code. Dit wordt standaard uitgevoerd in -O3.

In asm.js-modus wordt sluiting alleen gebruikt op de 'shell'-code rond de gecompileerde
code (de gecompileerde code wordt verwerkt door de aangepaste asm.js-minifier).

Opmerking: als de afsluitcompiler onvoldoende geheugen heeft, probeer dan JAVA_HEAP_SIZE aan te passen
de omgeving (bijvoorbeeld naar 4096m voor 4GB).

--js-transformatie
wordt aangeroepen op de gegenereerde code voordat deze wordt geoptimaliseerd. Dit laat je
verander de JavaScript, bijvoorbeeld door wat code toe te voegen of wat code te verwijderen, op een bepaalde manier
dat die aanpassingen samen met de gegenereerde code worden geoptimaliseerd
op de juiste manier. wordt aangeroepen met de bestandsnaam van de gegenereerde code als een
parameter; om de code te wijzigen, kunt u de originele gegevens lezen en er vervolgens aan toevoegen
of overschrijf het met de gewijzigde gegevens. wordt geïnterpreteerd als een ruimte-gescheiden
lijst met argumenten, bijv. van "python processor.py" zal een python
script uit te voeren.

--pre-js
Een bestand waarvan de inhoud vóór de gegenereerde code wordt toegevoegd. Dit is gedaan *voor*
optimalisatie, zodat het op de juiste manier wordt verkleind als de afsluitcompiler wordt uitgevoerd.

--post-js
Een bestand waarvan de inhoud na de gegenereerde code wordt toegevoegd. Dit gebeurt *voor*
optimalisatie, zodat het op de juiste manier wordt verkleind als de afsluitcompiler wordt uitgevoerd.

--embed-bestand
Een bestand om in te sluiten in het gegenereerde JavaScript. De gecompileerde code zal in staat zijn om
open het bestand in de huidige map met dezelfde naam als hier gegeven. Dus als
je doet --embed-bestand dir/file.dat, dan moet (1) dir/file.dat bestaan ​​ten opzichte van
waar u emcc uitvoert, en (2) uw gecompileerde code zal het bestand kunnen vinden door
datzelfde pad lezen, dir/file.dat. Als hier een map wordt doorgegeven, is deze volledig
inhoud zal worden ingesloten.

--preload-bestand
Een bestand om vooraf te laden voordat de gecompileerde code asynchroon wordt uitgevoerd. Anders
Soortgelijke --embed-bestand, behalve dat deze optie alleen relevant is bij het genereren
HTML (het gebruikt asynchrone binaire XHR's), of JS dat in een webpagina zal worden gebruikt. Als
een map wordt hier doorgegeven, de volledige inhoud wordt vooraf geladen. Vooraf geladen bestanden
worden opgeslagen in bestandsnaam.data, waarbij bestandsnaam.html het hoofdbestand is dat u aan het compileren bent
naar. Om uw code uit te voeren, heeft u zowel de .html als de .data nodig.

emcc voert tools/file_packager.py uit om de eigenlijke verpakking van ingebedde en
voorgeladen bestanden. U kunt de bestandsverpakker zelf uitvoeren als u dat wilt, zie docs
in dat bestand. U moet dan de uitvoer van de bestandsverpakker in een emcc
--pre-js, zodat het wordt uitgevoerd vóór uw gecompileerde hoofdcode (of voer het uit voordat in
op een andere manier).

--compressie
Comprimeer zowel de gecompileerde code als de ingesloten/voorgeladen bestanden. zou een moeten zijn
verdrievoudigen,

, ,

waarbij native_encoder een native uitvoerbaar bestand is dat stdin comprimeert naar stdout (de
eenvoudigst mogelijke interface), is js_decoder een JavaScript-bestand dat een
decoder, en js_name is de naam van de functie die moet worden aangeroepen in het decoderbestand (welke
moet een array/getypeerde array ontvangen en een array/getypeerde array retourneren. Compressie
werkt alleen bij het genereren van HTML. Als compressie is ingeschakeld, worden alle bestanden gespecificeerd als zijnde
voorgeladen worden gecomprimeerd in één groot archief, dat dezelfde naam krijgt als de
voer HTML uit maar met het achtervoegsel .data.compress

--kleineren
0: Verklein de gegenereerde JavaScript-witruimte niet (standaard in -O0, -O1, of als
-g is gebruikt)

1: Verklein de gegenereerde JavaScript's

witruimte (standaard in -O2+, veronderstellend -g het is niet gebruikt)

--gesplitst
Splitst het resulterende JavaScript-bestand in stukken om foutopsporing te vergemakkelijken. Deze optie
werkt alleen als Javascript is gegenereerd (target -o .js). Bestanden met functie
declaraties moeten bij uitvoering vóór het hoofdbestand worden geladen.

Zonder optie "-g":

Maakt bestanden met functiedeclaraties tot de opgegeven grootte met het achtervoegsel
"_functions.partxxx.js" en een hoofdbestand met het achtervoegsel ".js".

Met "-g" optie:

Herstelt de directorystructuur van de C-bronbestanden en slaat de functie op
declaraties in hun respectievelijke C-bestanden met het achtervoegsel ".js". Als zo'n bestand
de opgegeven grootte overschrijdt, worden bestanden met het achtervoegsel ".partxxx.js" aangemaakt. De belangrijkste
bestand bevindt zich in de basismap en heeft het achtervoegsel ".js".

--binden Compileert de broncode met behulp van de "embind"-bindingsbenadering, die C/C++ verbindt
en JS.

--ignore-dynamisch-linken Normaal behandelt emcc dynamisch linken zoals
statisch koppelen, door de code uit de dynamische bibliotheek te koppelen. Dit mislukt als de
dezelfde dynamische bibliotheek is meer dan eens gekoppeld. Met deze optie dynamisch linken
wordt genegeerd, waardoor het bouwsysteem zonder fouten kan doorgaan. Echter, jij
later zelf handmatig naar de gedeelde bibliotheken moet linken.

--shell-bestand
De padnaam naar een HTML-skeletbestand dat wordt gebruikt bij het genereren van HTML-uitvoer. De schelp
gebruikt bestand moet dit token bevatten: {{{ SCRIPT_CODE }}} Merk op dat this
argument wordt genegeerd als een ander doel dan HTML wordt opgegeven met de -o optie.

--js-bibliotheek
Een JavaScript-bibliotheek om te gebruiken naast die in Emscripten's src/library_*

-v Schakelt uitgebreide uitvoer in. Dit zal over gaan -v naar Clang, en schakel ook EMCC_DEBUG in
beschrijft de activiteiten van emcc

--jcache
Gebruik een JavaScript-cache. Dit is standaard uitgeschakeld. Indien ingeschakeld, zal emcc opslaan
de resultaten van compilatie in een cache en controleer de cache bij later compileren,
zoiets als wat ccache doet. Dit maakt incrementele builds mogelijk - waar u ook bent
een groot programma compileren, maar slechts een klein deel ervan aanpassen - om veel sneller te zijn
(ten koste van meer schijf-IO voor cachetoegang). Merk op dat u moet inschakelen
--jcache voor zowel het laden als opslaan van gegevens, dus u moet het inschakelen bij een volledige build
om een ​​latere incrementele build (waar u deze ook inschakelt) te versnellen.

Caching werkt afzonderlijk op 4 delen van de compilatie: 'pre', dat is typen en globaal
variabelen; die informatie wordt vervolgens ingevoerd in 'funcs', de functies (die
we parallelliseren), en dan 'post' die definitieve informatie toevoegt op basis van de
functies (hebben we bijvoorbeeld long64-ondersteuningscode nodig). Ten slotte zijn 'jsfuncs'
Optimalisaties op JavaScript-niveau. Elk van de 4 delen kan apart worden gecached, maar
merk op dat ze elkaar kunnen beïnvloeden: als u een enkel C++-bestand opnieuw compileert dat
verandert een globale variabele - bijvoorbeeld een globale variabele toevoegen, verwijderen of wijzigen
door een printf toe te voegen of door een compile-time timestamp toe te voegen, dan kan 'pre' dat niet zijn
geladen vanuit de cache. En aangezien de uitvoer van 'pre' wordt verzonden naar 'funcs' en 'post', zij
wordt ook ongeldig gemaakt en alleen 'jsfuncs' wordt in de cache opgeslagen. Vermijd dus wijzigingen
globals om caching volledig te laten werken.

Om het in de vorige paragraaf genoemde probleem te omzeilen, kunt u gebruiken

emscripten_jcache_printf

bij het toevoegen van debug printfs aan uw code. Die functie is speciaal zo voorbewerkt
dat het geen constante string globaal creëert voor zijn eerste argument. Zien
emscripten.h voor meer details. Merk in het bijzonder op dat u al een
roep die functie aan in uw code * voordat * u er een toevoegt en een incrementele functie uitvoert
build, zodat het toevoegen van een externe referentie (ook een globale eigenschap) dat niet doet
alles ongeldig maken.

Merk op dat u moet gebruiken -g tijdens de koppelingsfase (bitcode naar JS), voor jcache naar
werk (anders kan JS-minificatie het verwarren).

--Cache wissen
Wist handmatig de cache van gecompileerde emscripten-systeembibliotheken (libc++,
libc++abi, libc). Dit wordt normaal gesproken automatisch afgehandeld, maar als u llvm
in-place (in plaats van een andere map te hebben voor een nieuwe versie), de caching
mechanisme kan in de war raken. Het wissen van de cache kan rare problemen oplossen die verband houden met
cache onverenigbaarheden, zoals clang die niet kan linken met bibliotheekbestanden. Dit ook
wist andere gegevens in de cache, zoals de jcache en de bootstrapped relooper. Na de
cache is gewist, wordt dit proces afgesloten.

--opslaan-bc PATH
Bij het compileren naar JavaScript of HTML slaat deze optie een kopie van de bitcode op
naar het opgegeven pad. De bitcode bevat alle bestanden die worden gekoppeld, inclusief
standaardbibliotheken en na eventuele optimalisaties van de linktijd (indien van toepassing).

--memory-init-bestand
Indien ingeschakeld, genereren we een apart geheugeninitialisatiebestand. Dit is efficiënter
dan het opslaan van de geheugeninitialisatiegegevens die in JavaScript zijn ingesloten als tekst.
(standaard is uit)

Het doelbestand, indien gespecificeerd (-o ), definieert wat er zal worden gegenereerd:

.js
JavaScript

.html
HTML met ingesloten JavaScript

.bc
LLVM-bitcode (standaard)

.O
LLVM-bitcode (hetzelfde als .bc)

(Merk op dat als --memory-init-bestand wordt gebruikt, dan naast een .js- of .html-bestand
gegenereerd, verschijnt er ook een .mem-bestand.)

De -c optie (die gcc vertelt om de linker niet uit te voeren) zal ervoor zorgen dat LLVM bitcode wordt
gegenereerd, aangezien emcc alleen JavaScript genereert in de laatste koppelingsfase van het bouwen.

De invoerbestanden kunnen broncodebestanden zijn die Clang aankan (C of C++), LLVM
bitcode in binaire vorm of LLVM-assemblagebestanden in voor mensen leesbare vorm.

emcc wordt beïnvloed door verschillende omgevingsvariabelen. Bekijk de bron van emcc voor meer informatie
(zoek naar 'os.environ').

emcc: ondersteunde doelen: llvm bitcode, javascript, NOT elf (autoconf ziet graag elf
hierboven om ondersteuning voor gedeelde objecten in te schakelen)

COPYRIGHT

Copyright © 2013 de auteurs van Emscripten (zie AUTHORS.txt) Dit is gratis en open source
software onder de MIT-licentie. Er is GEEN garantie; zelfs niet voor VERKOOPBAARHEID of
GESCHIKTHEID VOOR EEN BEPAALD DOEL.

Gebruik emcc online met behulp van onworks.net-services