emcc - ອອນລາຍໃນຄລາວ

ໂຄງການ:

NAME

emcc - Emscripten compiler frontend

ລາຍລະອຽດ

emcc [ຕົວເລືອກ] ໄຟລ໌...

ຫຼາຍທີ່ສຸດ ປົກກະຕິ gcc/g++ ທາງເລືອກໃນການ ຈະ ເຮັດວຽກ, ສໍາລັບການ ຍົກຕົວຢ່າງ:
- ຊ່ວຍ ສະແດງຂໍ້ມູນນີ້

- ການປ່ຽນແປງ
ສະແດງຂໍ້ມູນສະບັບ compiler

ທາງເລືອກໃນການ ທີ່ ມີ ແກ້ໄຂ or ໃຫມ່ in emcc ປະກອບມີ:
-O0 ບໍ່ມີການເພີ່ມປະສິດທິພາບ (ຄ່າເລີ່ມຕົ້ນ)

-O1 ການເພີ່ມປະສິດທິພາບງ່າຍໆ, ລວມທັງ asm.js, LLVM -O1 ການເພີ່ມປະສິດທິພາບ, ແລະບໍ່ມີເວລາແລ່ນ
ການຢືນຢັນ ຫຼືການຈັບຂໍ້ຍົກເວັ້ນ C++ (ເພື່ອເປີດໃຊ້ການຈັບຂໍ້ຍົກເວັ້ນ C++ ຄືນໃໝ່, ໃຫ້ໃຊ້ -s
DISABLE_EXCEPTION_CATCHING=0 ). (ສໍາລັບລາຍລະອຽດກ່ຽວກັບຜົນກະທົບຂອງທາງເລືອກທີ່ແຕກຕ່າງກັນ
ລະດັບ, ເບິ່ງ apply_opt_level() ໃນ tools/shared.py ແລະ src/settings.js.) ໝາຍເຫດ:
ການເພີ່ມປະສິດທິພາບແມ່ນເຮັດໄດ້ພຽງແຕ່ເມື່ອລວບລວມກັບ JavaScript, ບໍ່ແມ່ນລະດັບກາງ
bitcode, *ເວັ້ນເສຍແຕ່* ເຈົ້າສ້າງດ້ວຍ EMCC_OPTIMIZE_NORMALLY=1 (ບໍ່ແນະນຳເວັ້ນເສຍແຕ່
ເຈົ້າຮູ້ວ່າເຈົ້າກໍາລັງເຮັດຫຍັງ!)

-O2 As -O1, ບວກກັບ relooper (loop recreation), LLVM -O2 ການເພີ່ມປະສິດທິພາບ, ແລະ

-s ALIASING_FUNCTION_POINTERS=1

-O3 As -O2, ບວກກັບການເພີ່ມປະສິດທິພາບອັນຕະລາຍທີ່ອາດຈະທໍາລາຍລະຫັດທີ່ສ້າງຂຶ້ນ! ນີ້ເພີ່ມ

-s FORCE_ALIGNED_MEMORY=1 -s DOUBLE_MODE=0 -s PRECISE_I64_MATH=0 --ປິດ 1
--llvm-lto 1

ອັນນີ້ບໍ່ແນະນຳເລີຍ. ຄວາມຄິດທີ່ດີກວ່າແມ່ນໃຫ້ພະຍາຍາມແຕ່ລະອັນນີ້ແຍກຕ່າງຫາກ
ດ້ານເທິງຂອງ -O2 ເພື່ອເບິ່ງສິ່ງທີ່ເຮັດວຽກ. ເບິ່ງ wiki ແລະ src/settings.js (ສໍາລັບ -s ທາງເລືອກ)
ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ.

-s OPTION=VALUE
ທາງເລືອກການສ້າງລະຫັດ JavaScript ເຂົ້າໄປໃນຕົວລວບລວມຂໍ້ມູນ emscripten. ສໍາ​ລັບ
ທາງເລືອກທີ່ມີຢູ່, ເບິ່ງ src/settings.js ໃຫ້ສັງເກດວ່າສໍາລັບທາງເລືອກທີ່ເປັນລາຍການ, ທ່ານ
ຕ້ອງການເຄື່ອງຫມາຍວົງຢືມໃນຫອຍສ່ວນໃຫຍ່, ສໍາລັບການຍົກຕົວຢ່າງ

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

or

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

(ໂດຍບໍ່ມີການ "s ພາຍນອກໃນທັງສອງອັນ, ທ່ານຈະໄດ້ຮັບຄວາມຜິດພາດ)

ນອກນັ້ນທ່ານຍັງສາມາດກໍານົດໄຟລ໌ຈາກຄ່າທີ່ຈະອ່ານ, ສໍາລັບການຍົກຕົວຢ່າງ,

-s DEAD_FUNCTIONS=@/path/to/file

ເນື້ອໃນຂອງ /path/to/file ຈະຖືກອ່ານ, JSON.parsed ແລະຕັ້ງເປັນ DEAD_FUNCTIONS
(ດັ່ງນັ້ນໄຟລ໌ສາມາດບັນຈຸ

["_func1", "func2"]

). ໃຫ້ສັງເກດວ່າເສັ້ນທາງຕ້ອງເປັນຢ່າງແທ້ຈິງ, ບໍ່ແມ່ນພີ່ນ້ອງ.

-g ໃຊ້ຂໍ້ມູນດີບັກ. ໃຫ້ສັງເກດວ່າທ່ານຕ້ອງການນີ້ໃນໄລຍະການລວບລວມສຸດທ້າຍຈາກ
bitcode ກັບ JavaScript, ຖ້າບໍ່ດັ່ງນັ້ນພວກເຮົາຈະເອົາມັນອອກໂດຍຄ່າເລີ່ມຕົ້ນໃນ -O1 ແລະຂ້າງເທິງ. ໃນ
-O0, ຕົວເລກແຖວຈະຖືກສະແດງຢູ່ໃນລະຫັດທີ່ສ້າງຂຶ້ນ. ໃນ -O1 ແລະຂ້າງເທິງ, ໄດ້
optimizer ເອົາຄໍາເຫັນເຫຼົ່ານັ້ນອອກ. ຢ່າງໃດກໍຕາມ, ທຸງນີ້ມີຜົນກະທົບຂອງ
ປິດ​ການ​ທໍາ​ງານ​ອັນ​ໃດ​ຫນຶ່ງ​ທີ່​ເຮັດ​ໃຫ້​ເກີດ​ການ​ເຊື່ອມ​ຕໍ່​ຫຼື​ການ​ຫຍໍ້​ຊື່ (ປິດ​ຫຼື​
ລົງທະບຽນຜ່ານ).

--typed-arrays
0: No typed arrays 1: Parallel typed arrays 2: Shared (C-like) typed arrays
(ຄ່າເລີ່ມຕົ້ນ)

--llvm-opts
0: ບໍ່ມີການເພີ່ມປະສິດທິພາບ LLVM (ຄ່າເລີ່ມຕົ້ນໃນ -O0) ປີ 1: -O1 ການເພີ່ມປະສິດທິພາບ LLVM (ຄ່າເລີ່ມຕົ້ນໃນ
-O1) ປີ 2: -O2 ການເພີ່ມປະສິດທິພາບ LLVM 3: -O3 ການເພີ່ມປະສິດທິພາບ LLVM (ຄ່າເລີ່ມຕົ້ນໃນ -O2+)

--llvm-lto
0: ບໍ່ມີ LLVM LTO (ຄ່າເລີ່ມຕົ້ນໃນ -O2 ແລະຂ້າງລຸ່ມນີ້) 1: LLVM LTO (ຄ່າເລີ່ມຕົ້ນໃນ -O3) ຫມາຍເຫດ: ຖ້າ
ການເພີ່ມປະສິດທິພາບ LLVM ບໍ່ໄດ້ດໍາເນີນການ (ເບິ່ງ --llvm-opts), ການຕັ້ງຄ່ານີ້ເປັນ 1 ບໍ່ມີຜົນ.

--ປິດ
0: ບໍ່ມີຕົວລວບລວມຂໍ້ມູນປິດ (ຄ່າເລີ່ມຕົ້ນໃນ -O2 ແລະຂ້າງລຸ່ມນີ້) 1: ດໍາເນີນການປິດ compiler. ນີ້
ຫຼຸດຜ່ອນຂະຫນາດລະຫັດຢ່າງຫຼວງຫຼາຍແລະໃນບາງກໍລະນີອາດຈະເພີ່ມຄວາມໄວ runtime (ເຖິງແມ່ນວ່າ
ກົງກັນຂ້າມຍັງສາມາດເກີດຂຶ້ນ). ໃຫ້ສັງເກດວ່າມັນໃຊ້ເວລາເພື່ອດໍາເນີນການ, ແລະອາດຈະຕ້ອງການບາງຢ່າງ
ການປ່ຽນແປງລະຫັດ. ນີ້ແມ່ນດໍາເນີນການໂດຍຄ່າເລີ່ມຕົ້ນໃນ -O3.

ໃນໂຫມດ asm.js, ການປິດຈະຖືກນໍາໃຊ້ພຽງແຕ່ຢູ່ໃນລະຫັດ 'shell' ທີ່ຢູ່ອ້ອມຮອບການລວບລວມ
code (ລະຫັດທີ່ລວບລວມຈະຖືກປະມວນຜົນໂດຍ custom asm.js minifier).

ໝາຍເຫດ: ຖ້າຕົວສັງລວມປິດຖືກກັບຄວາມຈຳທີ່ຢູ່ນອກ, ລອງປັບ JAVA_HEAP_SIZE ໃນ
ສະພາບແວດລ້ອມ (ຕົວຢ່າງ, ເຖິງ 4096m ສໍາລັບ 4GB).

--js-ຫັນ
ຈະຖືກເອີ້ນໃສ່ລະຫັດທີ່ສ້າງຂຶ້ນກ່ອນທີ່ຈະຖືກປັບໃຫ້ເໝາະສົມ. ນີ້ເຮັດໃຫ້ທ່ານ
ປັບປຸງແກ້ໄຂ JavaScript, ຕົວຢ່າງເຊັ່ນການເພີ່ມລະຫັດບາງຢ່າງຫຼືການຖອນລະຫັດບາງຢ່າງ, ໃນທາງຫນຶ່ງ
ວ່າການດັດແກ້ເຫຼົ່ານັ້ນຈະຖືກປັບປຸງໃຫ້ເໝາະສົມພ້ອມກັບລະຫັດທີ່ສ້າງຂຶ້ນ
ຢ່າງຖືກຕ້ອງ. ຈະຖືກເອີ້ນດ້ວຍຊື່ໄຟລ໌ຂອງລະຫັດທີ່ສ້າງຂຶ້ນເປັນ a
ພາລາມິເຕີ; ເພື່ອແກ້ໄຂລະຫັດ, ທ່ານສາມາດອ່ານຂໍ້ມູນຕົ້ນສະບັບແລະຫຼັງຈາກນັ້ນຕື່ມໃສ່ມັນ
ຫຼືຂຽນທັບມັນດ້ວຍຂໍ້ມູນທີ່ດັດແກ້. ຖືກຕີຄວາມໝາຍວ່າເປັນຊ່ອງແຍກ
ບັນຊີລາຍຊື່ຂອງການໂຕ້ຖຽງ, ສໍາລັບຕົວຢ່າງ, ຂອງ "python processor.py" ຈະເຮັດໃຫ້ເກີດ python
script ທີ່ຈະດໍາເນີນການ.

--pre-js
ໄຟລ໌ທີ່ເນື້ອຫາຈະຖືກເພີ່ມກ່ອນລະຫັດທີ່ສ້າງຂຶ້ນ. ນີ້ແມ່ນເຮັດ * ກ່ອນ *
ການເພີ່ມປະສິດທິພາບ, ດັ່ງນັ້ນມັນຈະຖືກຫຼຸດລົງຢ່າງຖືກຕ້ອງຖ້າປິດການລວບລວມຂໍ້ມູນຖືກດໍາເນີນການ.

--post-js
ໄຟລ໌ທີ່ເນື້ອຫາຈະຖືກເພີ່ມຫຼັງຈາກລະຫັດທີ່ສ້າງຂຶ້ນ ອັນນີ້ຖືກເຮັດ *ກ່ອນ*
ການເພີ່ມປະສິດທິພາບ, ດັ່ງນັ້ນມັນຈະຖືກຫຼຸດລົງຢ່າງຖືກຕ້ອງຖ້າປິດການລວບລວມຂໍ້ມູນຖືກດໍາເນີນການ.

--embed-file
ໄຟລ໌ທີ່ຈະຝັງຢູ່ໃນ JavaScript ທີ່ສ້າງຂຶ້ນ. ລະຫັດທີ່ລວບລວມຈະສາມາດ
ເຂົ້າເຖິງໄຟລ໌ໃນໄດເລກະທໍລີປະຈຸບັນທີ່ມີຊື່ດຽວກັນກັບທີ່ໃຫ້ຢູ່ທີ່ນີ້. ດັ່ງນັ້ນຖ້າ
ເຈົ້າ​ເຮັດ --embed-file dir/file.dat, ຈາກນັ້ນ (1) dir/file.dat ຕ້ອງມີຢູ່ກັບ
ບ່ອນ​ທີ່​ທ່ານ​ດໍາ​ເນີນ​ການ emcc​, ແລະ (2​) ລະ​ຫັດ​ທີ່​ສັງ​ລວມ​ຂອງ​ທ່ານ​ຈະ​ສາ​ມາດ​ຊອກ​ຫາ​ໄຟລ​໌​ໂດຍ​
ອ່ານເສັ້ນທາງດຽວກັນນັ້ນ, dir/file.dat. ຖ້າໄດເລກະທໍລີຖືກຜ່ານທີ່ນີ້, ທັງຫມົດຂອງມັນ
ເນື້ອໃນຈະຖືກຝັງ.

--preload-file
ໄຟລ໌ທີ່ຕ້ອງໂຫລດລ່ວງໜ້າກ່ອນທີ່ຈະແລ່ນລະຫັດທີ່ລວບລວມແລ້ວບໍ່ຊິ້ງ. ຖ້າບໍ່ດັ່ງນັ້ນ
ຄ້າຍ​ຄື​ກັບ --embed-file, ຍົກເວັ້ນວ່າຕົວເລືອກນີ້ມີຄວາມກ່ຽວຂ້ອງພຽງແຕ່ໃນເວລາທີ່ສ້າງ
HTML (ມັນໃຊ້ asynchronous binary XHRs), ຫຼື JS ທີ່ຈະໃຊ້ໃນຫນ້າເວັບ. ຖ້າ
ໄດເລກະທໍລີຖືກສົ່ງຜ່ານຢູ່ທີ່ນີ້, ເນື້ອຫາທັງຫມົດຂອງມັນຈະຖືກໂຫລດໄວ້ລ່ວງຫນ້າ. ໄຟລ໌ທີ່ໂຫລດໄວ້ລ່ວງໜ້າ
ຖືກເກັບໄວ້ໃນ filename.data, ບ່ອນທີ່ filename.html ແມ່ນໄຟລ໌ຕົ້ນຕໍທີ່ທ່ານກໍາລັງລວບລວມ
ກັບ. ເພື່ອແລ່ນລະຫັດຂອງທ່ານ, ທ່ານຈະຕ້ອງມີທັງ .html ແລະ .data.

emcc ແລ່ນເຄື່ອງມື/file_packager.py ເພື່ອເຮັດການຫຸ້ມຫໍ່ຕົວຈິງຂອງຝັງ ແລະ
ໄຟລ໌ທີ່ໂຫລດໄວ້ລ່ວງໜ້າ. ທ່ານສາມາດດໍາເນີນການຫຸ້ມຫໍ່ໄຟລ໌ຕົວທ່ານເອງຖ້າຫາກວ່າທ່ານຕ້ອງການ, ເບິ່ງ docs
ພາຍໃນໄຟລ໌ນັ້ນ. ຫຼັງຈາກນັ້ນ, ທ່ານຄວນເອົາຜົນຜະລິດຂອງໄຟລ໌ຫຸ້ມຫໍ່ຢູ່ໃນ emcc
--pre-js, ເພື່ອ​ໃຫ້​ມັນ​ດໍາ​ເນີນ​ການ​ກ່ອນ​ທີ່​ຈະ​ລະ​ຫັດ​ທີ່​ສົມ​ບູນ​ຂອງ​ທ່ານ (ຫຼື​ດໍາ​ເນີນ​ການ​ກ່ອນ​ທີ່​ຈະ​ເຂົ້າ​ໄປ​ໃນ​
ໃນທາງອື່ນ).

--ການບີບອັດ
ບີບອັດທັງລະຫັດທີ່ລວບລວມແລະຝັງ / ໄຟລ໌ທີ່ໂຫລດໄວ້ກ່ອນ. ຄວນຈະເປັນ
ສາມ​ເທົ່າ​,

, ,

ບ່ອນທີ່ native_encoder ເປັນ native executable ທີ່ບີບອັດ stdin ໄປ stdout (the
ການໂຕ້ຕອບທີ່ງ່າຍທີ່ສຸດທີ່ເປັນໄປໄດ້), js_decoder ແມ່ນໄຟລ໌ JavaScript ທີ່ປະຕິບັດ a
decoder, ແລະ js_name ແມ່ນຊື່ຂອງຟັງຊັນທີ່ຈະໂທຫາໃນໄຟລ໌ decoder (ຊຶ່ງ
ຄວນໄດ້ຮັບ array/typed array ແລະສົ່ງຄືນ array/typed array. ການບີບອັດ
ເຮັດວຽກພຽງແຕ່ໃນເວລາທີ່ສ້າງ HTML. ເມື່ອການບີບອັດເປີດ, ໄຟລ໌ທັງໝົດທີ່ລະບຸວ່າເປັນ
preloaded ຖືກບີບອັດຢູ່ໃນບ່ອນເກັບມ້ຽນໃຫຍ່ອັນຫນຶ່ງ, ເຊິ່ງໃຫ້ຊື່ດຽວກັນກັບ
ສົ່ງອອກ HTML ແຕ່ມີ suffix .data.compress

-- ຫຍໍ້
0: ຢ່າຫຍໍ້ຊ່ອງຫວ່າງຂອງ JavaScript ທີ່ສ້າງຂຶ້ນ (ຄ່າເລີ່ມຕົ້ນໃນ -O0, -O1, ຫຼືຖ້າ
-g ຖືກນໍາໃຊ້)

1: ຫຍໍ້ JavaScript ທີ່ສ້າງຂຶ້ນ

ຍະຫວ່າງ (ຄ່າເລີ່ມຕົ້ນໃນ -O2+, ສົມມຸດ -g ບໍ່ໄດ້ໃຊ້)

-- ແຍກ
ແບ່ງໄຟລ໌ javascript ທີ່ເປັນຜົນອອກມາເປັນຕ່ອນໆເພື່ອຄວາມສະດວກໃນການດີບັກ. ທາງເລືອກນີ້
ເຮັດວຽກພຽງແຕ່ຖ້າ Javascript ຖືກສ້າງຂຶ້ນ (ເປົ້າຫມາຍ -o .js). ໄຟລ໌ທີ່ມີຟັງຊັນ
ການປະກາດຈະຕ້ອງຖືກໂຫລດກ່ອນໄຟລ໌ຫຼັກເມື່ອດໍາເນີນການ.

ບໍ່ມີທາງເລືອກ "-g":

ສ້າງໄຟລ໌ທີ່ມີການປະກາດຟັງຊັນເຖິງຂະຫນາດທີ່ກໍານົດໄວ້ດ້ວຍຄໍາຕໍ່ທ້າຍ
"_functions.partxxx.js" ແລະໄຟລ໌ຫຼັກທີ່ມີຄຳຕໍ່ທ້າຍ ".js".

ດ້ວຍຕົວເລືອກ "-g":

ສ້າງໂຄງສ້າງໄດເລກະທໍລີຂອງໄຟລ໌ແຫຼ່ງ C ແລະຟັງຊັນເກັບຮັກສາ
ການປະກາດໃນໄຟລ໌ C ຂອງພວກເຂົາດ້ວຍຄໍາຕໍ່ທ້າຍ ".js". ຖ້າໄຟລ໌ດັ່ງກ່າວ
ເກີນຂະໜາດທີ່ກຳນົດໄວ້, ໄຟລ໌ທີ່ມີຄຳຕໍ່ທ້າຍ ".partxxx.js" ແມ່ນຖືກສ້າງຂຶ້ນ. ຕົ້ນຕໍ
ໄຟລ໌ຢູ່ໃນໄດເລກະທໍລີພື້ນຖານແລະມີ ".js".

-- ຜູກມັດ ລວບລວມລະຫັດແຫຼ່ງໂດຍໃຊ້ວິທີການ "embind", ເຊິ່ງເຊື່ອມຕໍ່ C/C++
ແລະ JS.

--ignore-dynamic-linking ໂດຍປົກກະຕິ emcc ຈະປະຕິບັດການເຊື່ອມຕໍ່ແບບເຄື່ອນໄຫວເຊັ່ນ
ການເຊື່ອມໂຍງແບບຄົງທີ່, ໂດຍການເຊື່ອມໂຍງໃນລະຫັດຈາກຫ້ອງສະຫມຸດແບບເຄື່ອນໄຫວ. ນີ້ລົ້ມເຫລວຖ້າຫາກວ່າ
ຫ້ອງສະຫມຸດແບບເຄື່ອນໄຫວດຽວກັນແມ່ນເຊື່ອມຕໍ່ຫຼາຍກວ່າຫນຶ່ງຄັ້ງ. ດ້ວຍທາງເລືອກນີ້, ການເຊື່ອມໂຍງແບບເຄື່ອນໄຫວ
ຖືກລະເລີຍ, ເຊິ່ງອະນຸຍາດໃຫ້ລະບົບການກໍ່ສ້າງດໍາເນີນການໂດຍບໍ່ມີຂໍ້ຜິດພາດ. ຢ່າງໃດກໍຕາມ, ທ່ານ
ຈະຕ້ອງເຊື່ອມຕໍ່ດ້ວຍຕົນເອງກັບຫ້ອງສະໝຸດທີ່ແບ່ງປັນໃນພາຍຫຼັງດ້ວຍຕົນເອງ.

--shell-file
ຊື່ເສັ້ນທາງໄປຫາໄຟລ໌ HTML skeleton ທີ່ໃຊ້ໃນເວລາສ້າງຜົນຜະລິດ HTML. ແກະ
ໄຟລ໌ທີ່ໃຊ້ຕ້ອງມີ token ນີ້ຢູ່ໃນມັນ: {{{ SCRIPT_CODE }}} ໃຫ້ສັງເກດວ່າອັນນີ້
argument ແມ່ນຖືກລະເລີຍຖ້າເປົ້າຫມາຍອື່ນທີ່ບໍ່ແມ່ນ HTML ຖືກລະບຸໂດຍໃຊ້ -o ທາງເລືອກ.

--js-library
ຫ້ອງສະໝຸດ JavaScript ທີ່ຈະໃຊ້ນອກເໜືອໄປຈາກທີ່ຢູ່ໃນ src/library_* ຂອງ Emscripten

-v ເປີດໃຊ້ການສົ່ງອອກ verbose. ນີ້ຈະຜ່ານ -v ເພື່ອ Clang, ແລະຍັງເປີດໃຊ້ EMCC_DEBUG ເພື່ອ
ລາຍລະອຽດການດໍາເນີນງານຂອງ emcc

--jcache
ໃຊ້ cache JavaScript. ອັນນີ້ຖືກປິດໃຊ້ງານໂດຍຄ່າເລີ່ມຕົ້ນ. ເມື່ອເປີດໃຊ້, emcc ຈະເກັບຮັກສາ
ຜົນໄດ້ຮັບຂອງການລວບລວມຂໍ້ມູນໃນ cache ແລະກວດເບິ່ງ cache ໃນເວລາລວບລວມຕໍ່ມາ,
ບາງສິ່ງບາງຢ່າງເຊັ່ນ: ສິ່ງທີ່ ccache ເຮັດ. ນີ້ອະນຸຍາດໃຫ້ເພີ່ມຂຶ້ນໃນການກໍ່ສ້າງ - ບ່ອນທີ່ທ່ານຢູ່
ການລວບລວມໂຄງການຂະຫນາດໃຫຍ່ແຕ່ພຽງແຕ່ດັດແກ້ສ່ວນນ້ອຍໆຂອງມັນ - ເພື່ອໃຫ້ໄວຂຶ້ນຫຼາຍ
(ໃນຄ່າໃຊ້ຈ່າຍຂອງ disk IO ເພີ່ມເຕີມສໍາລັບການເຂົ້າເຖິງ cache). ໃຫ້ສັງເກດວ່າທ່ານຈໍາເປັນຕ້ອງເປີດໃຊ້
--jcache ສໍາລັບການໂຫຼດແລະການປະຫຍັດຂໍ້ມູນ, ດັ່ງນັ້ນທ່ານຕ້ອງເປີດໃຊ້ມັນໃນການກໍ່ສ້າງເຕັມ
ສໍາລັບການກໍ່ສ້າງທີ່ເພີ່ມຂຶ້ນຕໍ່ມາ (ບ່ອນທີ່ທ່ານຍັງເປີດໃຊ້ມັນ) ເພື່ອເລັ່ງ.

Caching ເຮັດວຽກແຍກຕ່າງຫາກຢູ່ໃນ 4 ພາກສ່ວນຂອງການລວບລວມ: 'pre' ເຊິ່ງເປັນປະເພດແລະທົ່ວໂລກ
ຕົວແປ; ຂໍ້ມູນນັ້ນຈະຖືກປ້ອນເຂົ້າໄປໃນ 'funcs' ເຊິ່ງເປັນຫນ້າທີ່ (ເຊິ່ງ
ພວກເຮົາ parallelize), ແລະຫຼັງຈາກນັ້ນ 'ໂພດ' ເຊິ່ງເພີ່ມຂໍ້ມູນສຸດທ້າຍໂດຍອີງໃສ່
functions (ເຊັ່ນ: ພວກເຮົາຕ້ອງການລະຫັດສະຫນັບສະຫນູນ long64). ສຸດທ້າຍ, 'jsfuncs' ແມ່ນ
ການເພີ່ມປະສິດທິພາບລະດັບ JavaScript. ແຕ່ລະ 4 ພາກສ່ວນສາມາດຖືກເກັບໄວ້ແຍກຕ່າງຫາກ, ແຕ່
ໃຫ້ສັງເກດວ່າພວກມັນສາມາດສົ່ງຜົນກະທົບຕໍ່ກັນແລະກັນ: ຖ້າທ່ານລວບລວມໄຟລ໌ C ++ ດຽວທີ່
ປ່ຽນຕົວແປທົ່ວໂລກ - ຕົວຢ່າງ, ເພີ່ມ, ເອົາອອກ ຫຼືແກ້ໄຂຕົວແປທົ່ວໂລກ, ເວົ້າ
ໂດຍການເພີ່ມ printf ຫຼືໂດຍການເພີ່ມເວລາລວບລວມເວລາ, ຫຼັງຈາກນັ້ນ 'pre' ບໍ່ສາມາດເປັນ
ໂຫລດຈາກ cache. ແລະນັບຕັ້ງແຕ່ 'pre's output ຖືກສົ່ງໄປຫາ 'funcs' ແລະ 'post', ພວກເຂົາ
ຈະຖືກຍົກເລີກເຊັ່ນດຽວກັນ, ແລະພຽງແຕ່ 'jsfuncs' ຈະຖືກເກັບໄວ້ໃນຖານຄວາມຈໍາ. ສະນັ້ນຫຼີກເວັ້ນການດັດແປງ
ທົ່ວໂລກເພື່ອໃຫ້ຖານຄວາມຈໍາເຮັດວຽກໄດ້ຢ່າງເຕັມສ່ວນ.

ເພື່ອແກ້ໄຂບັນຫາທີ່ໄດ້ກ່າວມາໃນວັກທີ່ຜ່ານມາ, ທ່ານສາມາດນໍາໃຊ້

emscripten_jcache_printf

ເມື່ອເພີ່ມ debug printfs ໃສ່ລະຫັດຂອງທ່ານ. ຟັງຊັນນັ້ນຖືກປຸງແຕ່ງເປັນພິເສດ
ວ່າມັນບໍ່ໄດ້ສ້າງ string ຄົງທີ່ທົ່ວໂລກສໍາລັບການ argument ທໍາອິດຂອງຕົນ. ເບິ່ງ
emscripten.h ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມ. ໃຫ້ສັງເກດວ່າໂດຍສະເພາະທ່ານຈໍາເປັນຕ້ອງມີແລ້ວ
ໂທຫາຟັງຊັນນັ້ນໃນລະຫັດຂອງທ່ານ * ກ່ອນທີ່ທ່ານຈະເພີ່ມຫນຶ່ງແລະເຮັດການເພີ່ມ
ກໍ່ສ້າງ, ດັ່ງນັ້ນການເພີ່ມການອ້າງອີງພາຍນອກ (ຍັງເປັນຊັບສິນທົ່ວໂລກ) ບໍ່ໄດ້
ບໍ່ຖືກຕ້ອງທຸກຢ່າງ.

ໃຫ້ສັງເກດວ່າທ່ານຄວນໃຊ້ -g ໃນລະຫວ່າງຂັ້ນຕອນການເຊື່ອມໂຍງ (bitcode ກັບ JS), ສໍາລັບ jcache ກັບ
ເຮັດວຽກ (ຖ້າບໍ່ດັ່ງນັ້ນ, JS minification ສາມາດສັບສົນມັນ).

--clear-cache
ລ້າງແຄດຂອງຫ້ອງສະໝຸດລະບົບ emscripten ທີ່ລວບລວມດ້ວຍຕົນເອງ (libc++,
libc++abi, libc). ປົກກະຕິນີ້ແມ່ນການຈັດການອັດຕະໂນມັດ, ແຕ່ຖ້າທ່ານອັບເດດ llvm
in-place (ແທນທີ່ຈະມີໄດເລກະທໍລີທີ່ແຕກຕ່າງກັນສໍາລັບສະບັບໃຫມ່), cache
ກົນໄກສາມາດສັບສົນ. ການລ້າງແຄດສາມາດແກ້ໄຂບັນຫາແປກໆທີ່ກ່ຽວຂ້ອງກັບ
ຄວາມບໍ່ເຂົ້າກັນຂອງ cache, ເຊັ່ນ: clang ບໍ່ສາມາດເຊື່ອມຕໍ່ກັບໄຟລ໌ຫ້ອງສະຫມຸດ. ອັນນີ້
ລ້າງຂໍ້ມູນແຄດອື່ນເຊັ່ນ jcache ແລະ bootstrapped relooper. ຫຼັງຈາກ
cache ຖືກລຶບລ້າງ, ຂະບວນການນີ້ຈະອອກ.

--save-bc PATH
ເມື່ອລວບລວມເປັນ JavaScript ຫຼື HTML, ຕົວເລືອກນີ້ຈະບັນທຶກສໍາເນົາຂອງ bitcode
ໄປ​ສູ່​ເສັ້ນ​ທາງ​ທີ່​ກໍາ​ນົດ​ໄວ້​. bitcode ຈະປະກອບມີໄຟລ໌ທັງຫມົດທີ່ເຊື່ອມຕໍ່, ລວມທັງ
ຫ້ອງສະຫມຸດມາດຕະຖານ, ແລະຫຼັງຈາກການເພີ່ມປະສິດທິພາບການເຊື່ອມໂຍງເວລາໃດໆ (ຖ້າມີ).

--memory-init-file
ຖ້າເປີດຢູ່, ພວກເຮົາສ້າງໄຟລ໌ການເລີ່ມຕົ້ນຫນ່ວຍຄວາມຈໍາແຍກຕ່າງຫາກ. ນີ້ແມ່ນປະສິດທິພາບຫຼາຍ
ກ່ວາການເກັບຮັກສາຂໍ້ມູນເບື້ອງຕົ້ນຂອງຫນ່ວຍຄວາມຈໍາທີ່ຝັງຢູ່ໃນ JavaScript ເປັນຂໍ້ຄວາມ.
(ຄ່າເລີ່ມຕົ້ນຖືກປິດໄວ້)

ໄຟລ໌ເປົ້າໝາຍ, ຖ້າລະບຸ (-o ), ກໍານົດສິ່ງທີ່ຈະຖືກສ້າງຂຶ້ນ:

.js
JavaScript

.html
HTML ກັບ JavaScript ທີ່ຝັງໄວ້

.bc
LLVM bitcode (ຄ່າເລີ່ມຕົ້ນ)

.o
LLVM bitcode (ຄືກັນກັບ .bc)

(ໃຫ້ສັງເກດວ່າຖ້າ --memory-init-file ຖືກນໍາໃຊ້, ຫຼັງຈາກນັ້ນນອກຈາກໄຟລ໌ .js ຫຼື .html ທີ່ເປັນ
ສ້າງຂຶ້ນ, ໄຟລ໌ .mem ຈະປະກົດຂຶ້ນ.)

ໄດ້ -c ທາງເລືອກ (ທີ່ບອກ gcc ບໍ່ດໍາເນີນການ linker) ຈະເຮັດໃຫ້ LLVM bitcode ເປັນ
ສ້າງຂຶ້ນ, ຍ້ອນວ່າ emcc ພຽງແຕ່ສ້າງ JavaScript ໃນຂັ້ນຕອນການເຊື່ອມໂຍງສຸດທ້າຍຂອງການກໍ່ສ້າງ.

ໄຟລ໌ປ້ອນຂໍ້ມູນສາມາດເປັນໄຟລ໌ລະຫັດແຫຼ່ງທີ່ Clang ສາມາດຈັດການໄດ້ (C ຫຼື C++), LLVM
bitcode ໃນຮູບແບບຖານສອງ, ຫຼືໄຟລ໌ປະກອບ LLVM ໃນຮູບແບບທີ່ມະນຸດສາມາດອ່ານໄດ້.

emcc ໄດ້ຮັບຜົນກະທົບຈາກຕົວແປສະພາບແວດລ້ອມຫຼາຍອັນ. ສໍາລັບລາຍລະອຽດ, ເບິ່ງແຫຼ່ງຂອງ emcc
(ຄົ້ນຫາສໍາລັບ 'os.environ').

emcc: ເປົ້າໝາຍທີ່ຮອງຮັບ: llvm bitcode, javascript, NOT elf (autoconf ມັກເບິ່ງ elf
ຂ້າງ​ເທິງ​ເພື່ອ​ເປີດ​ການ​ສະ​ຫນັບ​ສະ​ຫນູນ​ວັດ​ຖຸ​ແບ່ງ​ປັນ​)

COPYRIGHT

ສະຫງວນລິຂະສິດ © 2013 ຜູ້ຂຽນ Emscripten (ເບິ່ງ AUTHORS.txt) ນີ້ແມ່ນແຫຼ່ງຟຣີ ແລະເປີດ.
ຊອບແວພາຍໃຕ້ໃບອະນຸຍາດ MIT. ບໍ່ມີການຮັບປະກັນ; ບໍ່ແມ່ນແຕ່ສໍາລັບ MERCHANTABILITY ຫຼື
ຈຸດປະສົງ ສຳ ລັບເປົ້າ ໝາຍ ຈຸດປະສົງ.

ໃຊ້ emcc ອອນໄລນ໌ໂດຍໃຊ້ບໍລິການ onworks.net