emcc - Online sa Cloud

PROGRAMA:

NAME

emcc - Emscripten compiler frontend

DESCRIPTION

emcc [mga opsyon] na file...

tulay normal gcc/g++ pagpipilian habilin trabaho, para halimbawa:
- Tumulong Ipakita ang impormasyong ito

--bersyon
Ipakita ang impormasyon ng bersyon ng compiler

Options na ay binago or bago in emcc ay kinabibilangan ng:
-O0 Walang mga pag-optimize (default)

-O1 Mga simpleng pag-optimize, kabilang ang asm.js, LLVM -O1 mga pag-optimize, at walang runtime
assertions o C++ exception catching (upang muling paganahin ang C++ exception catching, gamitin -s
DISABLE_EXCEPTION_CATCHING=0 ). (Para sa mga detalye sa mga epekto ng iba't ibang opt
mga antas, tingnan ang apply_opt_level() sa mga tool/shared.py at gayundin ang src/settings.js.) Tandaan:
Ginagawa lamang ang mga pag-optimize kapag nag-compile sa JavaScript, hindi sa intermediate
bitcode, *maliban kung* bumuo ka gamit ang EMCC_OPTIMIZE_NORMALLY=1 (hindi inirerekomenda maliban kung
alam mo ang ginagawa mo!)

-O2 As -O1, kasama ang relooper (loop recreation), LLVM -O2 pag-optimize, at

-s ALIASING_FUNCTION_POINTERS=1

-O3 As -O2, kasama ang mga mapanganib na pag-optimize na maaaring masira ang nabuong code! Dagdag pa nito

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

Ito ay hindi inirerekomenda sa lahat. Ang isang mas magandang ideya ay subukan ang bawat isa sa mga ito nang hiwalay
sa taas ng -O2 upang makita kung ano ang gumagana. Tingnan ang wiki at src/settings.js (para sa -s mga pagpipilian)
para sa karagdagang impormasyon.

-s OPTION=VALUE
Ang opsyon sa pagbuo ng code ng JavaScript ay ipinasa sa emscripten compiler. Para sa
magagamit na mga opsyon, tingnan ang src/settings.js Tandaan na para sa mga opsyon na mga listahan, ikaw
kailangan ng mga panipi sa karamihan ng mga shell, halimbawa

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

or

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

(nang walang panlabas na "s sa alinman sa mga iyon, magkakaroon ka ng error)

Maaari mo ring tukuyin ang isang file kung saan babasahin ang halaga, halimbawa,

-s DEAD_FUNCTIONS=@/path/to/file

Ang mga nilalaman ng /path/to/file ay babasahin, JSON.na-parse at itatakda sa DEAD_FUNCTIONS
(para ang file ay maaaring maglaman ng

["_func1", "func2"]

). Tandaan na ang landas ay dapat na ganap, hindi kamag-anak.

-g Gumamit ng impormasyon sa pag-debug. Tandaan na kailangan mo ito sa huling bahagi ng compilation mula sa
bitcode sa JavaScript, o kung hindi, aalisin namin ito bilang default sa -O1 at sa itaas. Sa
-O0, ang mga numero ng linya ay ipapakita sa nabuong code. Sa -O1 at sa itaas, ang
inaalis ng optimizer ang mga komentong iyon. Ang watawat na ito ay gayunpaman ay may epekto ng
hindi pagpapagana ng anumang bagay na nagdudulot ng pagkasira ng pangalan o pagpapaliit (pagsasara o ang
magparehistro ng pass).

--typed-arrays
0: Walang naka-type na array 1: Parallel typed array 2: Shared (C-like) typed array
(default)

--llvm-opts
0: Walang LLVM optimizations (default in -O0) 1: -O1 Mga pag-optimize ng LLVM (default sa
-O1) 2: -O2 Mga pag-optimize ng LLVM 3: -O3 Mga pag-optimize ng LLVM (default sa -O2+)

--llvm-lto
0: Walang LLVM LTO (default in -O2 at sa ibaba) 1: LLVM LTO (default in -O3) Tandaan: Kung
Ang mga pag-optimize ng LLVM ay hindi pinapatakbo (tingnan --llvm-opts), ang pagtatakda nito sa 1 ay walang epekto.

--pagsasara
0: Walang closure compiler (default in -O2 at sa ibaba) 1: Patakbuhin ang closure compiler. Ito
lubos na binabawasan ang laki ng code at maaaring sa ilang mga kaso ay tumaas ang bilis ng runtime (bagaman
ang kabaligtaran ay maaari ding mangyari). Tandaan na nangangailangan ng oras upang tumakbo, at maaaring mangailangan ng ilan
mga pagbabago sa code. Ito ay pinapatakbo bilang default sa -O3.

Sa asm.js mode, ang pagsasara ay gagamitin lamang sa 'shell' code sa paligid ng pinagsama-sama
code (ang pinagsama-samang code ay ipoproseso ng custom na asm.js minifier).

Tandaan: Kung ang closure compiler ay tumama sa isang out-of-memory, subukang ayusin ang JAVA_HEAP_SIZE sa
ang kapaligiran (halimbawa, sa 4096m para sa 4GB).

--js-transform
ay tatawagin sa nabuong code bago ito ma-optimize. Hinahayaan ka nito
baguhin ang JavaScript, halimbawa pagdaragdag ng ilang code o pag-alis ng ilang code, sa isang paraan
na ang mga pagbabagong iyon ay ma-optimize kasama ng nabuong code
ng maayos. ay tatawagin kasama ang filename ng nabuong code bilang a
parameter; upang baguhin ang code, maaari mong basahin ang orihinal na data at pagkatapos ay idagdag dito
o i-overwrite ito ng binagong data. ay binibigyang kahulugan bilang isang space-separated
listahan ng mga argumento, halimbawa, ng "python processor.py" ay magdudulot ng python
script na tatakbo.

--pre-js
Isang file na ang mga nilalaman ay idinagdag bago ang nabuong code. Ito ay tapos na *bago*
pag-optimize, kaya ito ay mababawasan nang maayos kung ang closure compiler ay tatakbo.

--post-js
Isang file na ang mga nilalaman ay idinagdag pagkatapos ng nabuong code Ginagawa ito *bago*
pag-optimize, kaya ito ay mababawasan nang maayos kung ang closure compiler ay tatakbo.

--embed-file
Isang file na i-embed sa loob ng nabuong JavaScript. Ang pinagsama-samang code ay magagawang
i-access ang file sa kasalukuyang direktoryo na may parehong pangalan tulad ng ibinigay dito. Kaya kung
ginagawa mo --embed-file dir/file.dat, pagkatapos (1) dapat na umiiral ang dir/file.dat na may kaugnayan sa
kung saan mo pinapatakbo ang emcc, at (2) mahahanap ng iyong pinagsama-samang code ang file sa pamamagitan ng
binabasa ang parehong landas, dir/file.dat. Kung ang isang direktoryo ay ipinasa dito, ang kabuuan nito
ang mga nilalaman ay i-embed.

--preload-file
Isang file na i-preload bago patakbuhin ang pinagsama-samang code nang asynchronous. Kung hindi
katulad ng --embed-file, maliban na ang pagpipiliang ito ay may kaugnayan lamang kapag bumubuo
HTML (gumagamit ito ng asynchronous binary XHRs), o JS na gagamitin sa isang web page. Kung
isang direktoryo ang ipinasa dito, ang buong nilalaman nito ay paunang mai-load. Na-preload na mga file
ay naka-imbak sa filename.data, kung saan ang filename.html ay ang pangunahing file na iyong kino-compile
sa. Upang patakbuhin ang iyong code, kakailanganin mo ang parehong .html at ang .data.

Ang emcc ay nagpapatakbo ng mga tool/file_packager.py upang gawin ang aktwal na packaging ng naka-embed at
paunang na-load na mga file. Maaari mong patakbuhin ang file packager sa iyong sarili kung gusto mo, tingnan ang docs
sa loob ng file na iyon. Dapat mong ilagay ang output ng file packager sa isang emcc
--pre-js, upang maisagawa ito bago ang iyong pangunahing pinagsama-samang code (o patakbuhin ito bago in
sa ibang paraan).

--compression
I-compress ang pinagsama-samang code at naka-embed/na-preload na mga file. dapat ay a
triple,

, ,

kung saan ang native_encoder ay isang katutubong executable na nag-compress ng stdin sa stdout (ang
pinakasimpleng posibleng interface), ang js_decoder ay isang JavaScript file na nagpapatupad ng a
decoder, at ang js_name ay ang pangalan ng function na tatawagan sa decoder file (na
dapat makatanggap ng array/typed array at magbalik ng array/typed array. Compression
gumagana lamang kapag bumubuo ng HTML. Kapag naka-on ang compression, tinukoy ang lahat ng file na
ang preloaded ay na-compress sa isang malaking archive, na binibigyan ng parehong pangalan bilang ang
output HTML ngunit may suffix na .data.compress

--minify
0: Huwag maliitin ang nabuong whitespace ng JavaScript (default sa -O0, -O1, o kaya
-g Ginagamit)

1: Bawasan ang nabuong JavaScript

whitespace (default sa -O2+, sa pag-aakalang -g ay hindi ginagamit)

--hati
Hinahati-hati ang nagresultang javascript file sa mga piraso upang mapadali ang pag-debug. Ang pagpipiliang ito
gagana lamang kung nabuo ang Javascript (target -o .js). Mga file na may function
ang mga deklarasyon ay dapat na mai-load bago ang pangunahing file sa pagpapatupad.

Nang walang "-g" na opsyon:

Gumagawa ng mga file na may mga deklarasyon ng function hanggang sa ibinigay na laki na may suffix
"_functions.partxxx.js" at isang pangunahing file na may suffix na ".js".

Gamit ang opsyong "-g":

Nililikha muli ang istraktura ng direktoryo ng mga C source file at function ng mga tindahan
mga deklarasyon sa kani-kanilang C file na may suffix na ".js". Kung ganoong file
lumampas sa ibinigay na laki, ang mga file na may suffix na ".partxxx.js" ay nilikha. Pangunahing
Ang file ay nasa base na direktoryo at may suffix na ".js".

--magbigkis Kino-compile ang source code gamit ang "embind" bindings approach, na nag-uugnay sa C/C++
at JS.

--ignore-dynamic-linking Karaniwang ituturing ng emcc ang dynamic na pag-link tulad ng
static na pag-link, sa pamamagitan ng pag-link sa code mula sa dynamic na library. Nabigo ito kung ang
ang parehong dynamic na library ay naka-link nang higit sa isang beses. Gamit ang opsyong ito, dynamic na pag-link
ay hindi pinansin, na nagpapahintulot sa build system na magpatuloy nang walang mga error. Gayunpaman, ikaw
kakailanganin mong manu-manong mag-link sa mga nakabahaging aklatan sa ibang pagkakataon sa iyong sarili.

--shell-file
Ang pangalan ng path sa isang skeleton HTML file na ginagamit kapag bumubuo ng HTML na output. Ang shell
Ang file na ginamit ay kailangang may ganitong token sa loob nito: {{{ SCRIPT_CODE }}} Tandaan na ito
Ang argumento ay binabalewala kung ang isang target maliban sa HTML ay tinukoy gamit ang -o pagpipilian.

--js-library
Isang JavaScript library na gagamitin bilang karagdagan sa mga nasa src/library_* ni Emscripten

-v Ino-on ang verbose output. Lilipas ito -v sa Clang, at paganahin din ang EMCC_DEBUG sa
mga detalye ng pagpapatakbo ng emcc

--jcache
Gumamit ng JavaScript cache. Ito ay hindi pinagana bilang default. Kapag pinagana, mag-iimbak ang emcc
ang mga resulta ng compilation sa isang cache at suriin ang cache kapag kino-compile sa ibang pagkakataon,
tulad ng ginagawa ng ccache. Nagbibigay-daan ito sa mga incremental na build - kung nasaan ka
pag-compile ng isang malaking program ngunit binago lamang ang isang maliit na bahagi nito - upang maging mas mabilis
(sa halaga ng mas maraming disk IO para sa mga pag-access sa cache). Tandaan na kailangan mong paganahin
--jcache para sa parehong pag-load at pag-save ng data, kaya dapat mong paganahin ito sa isang buong build
para sa susunod na incremental build (kung saan mo rin ito pinagana) na mapabilis.

Ang pag-cache ay gumagana nang hiwalay sa 4 na bahagi ng compilation: 'pre' na mga uri at global
mga variable; ang impormasyong iyon ay ipapakain sa 'funcs' na siyang mga function (na
kami ay parallelize), at pagkatapos ay 'post' na nagdaragdag ng panghuling impormasyon batay sa
function (hal., kailangan ba natin ng long64 support code). Sa wakas, ang 'jsfuncs' ay
Mga pag-optimize sa antas ng JavaScript. Ang bawat isa sa 4 na bahagi ay maaaring i-cache nang hiwalay, ngunit
tandaan na maaari silang makaapekto sa isa't isa: Kung mag-recompile ka ng isang C++ file na iyon
nagbabago ng pandaigdigang variable - hal., nagdaragdag, nag-aalis o nagbabago ng pandaigdigang variable, sabihin
sa pamamagitan ng pagdaragdag ng isang printf o sa pamamagitan ng pagdaragdag ng isang compile-time timestamp, kung gayon ang 'pre' ay hindi maaaring
na-load mula sa cache. At dahil ang 'pre's output ay ipinadala sa 'funcs' at 'post', sila
ay mawawalan din ng bisa, at ang mga 'jsfuncs' lang ang mai-cache. Kaya iwasan ang pagbabago
globals upang hayaang ganap na gumana ang caching.

Upang malutas ang problemang nabanggit sa nakaraang talata, maaari mong gamitin

emscripten_jcache_printf

kapag nagdaragdag ng mga debug printfs sa iyong code. Ang function na iyon ay espesyal na na-preprocess kaya
na hindi ito lumilikha ng isang palaging string global para sa unang argumento nito. Tingnan mo
emscripten.h para sa higit pang mga detalye. Tandaan sa partikular na kailangan mo nang magkaroon ng a
tumawag sa function na iyon sa iyong code *bago* ka magdagdag ng isa at gumawa ng incremental
build, upang ang pagdaragdag ng isang panlabas na sanggunian (isang pandaigdigang pag-aari) ay hindi
invalidate lahat.

Tandaan na dapat mong gamitin -g sa yugto ng pagli-link (bitcode sa JS), para sa jcache sa
trabaho (kung hindi, maaaring malito ito ng JS minification).

--clear-cache
Manu-manong nililimas ang cache ng mga pinagsama-samang emscripten system na library (libc++,
libc++abi, libc). Ito ay karaniwang awtomatikong pinangangasiwaan, ngunit kung i-update mo ang llvm
in-place (sa halip na magkaroon ng ibang direktoryo para sa isang bagong bersyon), ang pag-cache
maaaring malito ang mekanismo. Ang pag-clear sa cache ay maaaring ayusin ang mga kakaibang problema na nauugnay sa
cache incompatibilities, tulad ng clang na hindi nag-link sa mga file ng library. Ito rin
ni-clear ang iba pang naka-cache na data tulad ng jcache at ang bootstrapped relooper. Pagkatapos ng
na-clear ang cache, lalabas ang prosesong ito.

--save-bc PATH
Kapag nag-compile sa JavaScript o HTML, ang opsyong ito ay magse-save ng kopya ng bitcode
sa tinukoy na landas. Isasama sa bitcode ang lahat ng mga file na naka-link, kabilang ang
karaniwang mga aklatan, at pagkatapos ng anumang pag-optimize ng oras ng pag-link (kung mayroon man).

--memory-init-file
Kung naka-on, bubuo kami ng hiwalay na memory initialization file. Ito ay mas mahusay
kaysa sa pag-imbak ng data ng pagsisimula ng memorya na naka-embed sa loob ng JavaScript bilang teksto.
(naka-off ang default)

Ang target na file, kung tinukoy (-o ), ay tumutukoy kung ano ang bubuo:

.js
JavaScript

.html
HTML na may naka-embed na JavaScript

.bc
LLVM bitcode (default)

.o
LLVM bitcode (katulad ng .bc)

(Tandaan na kung --memory-init-file ay ginagamit, pagkatapos ay bilang karagdagan sa isang .js o .html file na
nabuo, lalabas din ang isang .mem file.)

Ang -c opsyon (na nagsasabi sa gcc na huwag patakbuhin ang linker) ay magiging sanhi ng LLVM bitcode
nabuo, dahil ang emcc ay bumubuo lamang ng JavaScript sa huling yugto ng pag-link ng gusali.

Ang (mga) input file ay maaaring alinman sa source code file na kayang hawakan ni Clang (C o C++), LLVM
bitcode sa binary form, o LLVM assembly file sa human-readable form.

Ang emcc ay apektado ng ilang mga variable ng kapaligiran. Para sa mga detalye, tingnan ang pinagmulan ng emcc
(hanapin ang 'os.environ').

emcc: mga sinusuportahang target: llvm bitcode, javascript, HINDI duwende (gustong makita ng autoconf ang duwende
sa itaas upang paganahin ang suporta sa nakabahaging object)

COPYRIGHT

Copyright © 2013 the Emscripten authors (see AUTHORS.txt) Ito ay libre at open source
software sa ilalim ng lisensya ng MIT. WALANG warranty; hindi kahit para sa MERCHANTABILITY o
KASANAYAN PARA SA ISANG KASUNDUAN NA LAYUNIN.

Gamitin ang emcc online gamit ang mga serbisyo ng onworks.net