emcc - Online na nuvem

PROGRAMA:

NOME

emcc - interface do compilador Emscripten

DESCRIÇÃO

emcc [arquivo de opções] ...

Os mais normal gcc / g ++ opções precisarão trabalhar, para exemplo:
--Socorro Exibir esta informação

--versão
Exibir informações da versão do compilador

Opções que e guarante que os mesmos estão modificada or novo in emcc incluem:
-O0 Sem otimizações (padrão)

-O1 Otimizações simples, incluindo asm.js, LLVM -O1 otimizações e sem tempo de execução
asserções ou captura de exceção C ++ (para reativar a captura de exceção C ++, use -s
DISABLE_EXCEPTION_CATCHING = 0). (Para obter detalhes sobre os efeitos de diferentes opções
níveis, consulte apply_opt_level () em tools / shared.py e também src / settings.js.) Nota:
As otimizações são feitas apenas durante a compilação para JavaScript, não para o intermediário
bitcode, * a menos * que você construa com EMCC_OPTIMIZE_NORMALLY = 1 (não recomendado, a menos que
você sabe o que está fazendo!)

-O2 As -O1, mais o relooper (recriação de loop), LLVM -O2 otimizações e

-s ALIASING_FUNCTION_POINTERS = 1

-O3 As -O2, além de otimizações perigosas que podem quebrar o código gerado! Isso adiciona

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

Isso não é recomendado de forma alguma. Uma ideia melhor é experimentar cada um deles separadamente em
topo de -O2 para ver o que funciona. Veja o wiki e src / settings.js (para o -s opções)
para obter mais informações.

-s OPÇÃO = VALOR
Opção de geração de código JavaScript passada para o compilador emscripten. Para o
opções disponíveis, consulte src / settings.js. Observe que, para opções que são listas, você
precisa de aspas na maioria das conchas, por exemplo

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

or

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

(sem os "s externos em qualquer um deles, você obteria um erro)

Você também pode especificar um arquivo a partir do qual o valor seria lido, por exemplo,

-s DEAD_FUNCTIONS = @ / caminho / para / arquivo

O conteúdo de / caminho / para / arquivo será lido, JSON.parsed e definido em DEAD_FUNCTIONS
(então o arquivo pode conter

["_func1", "func2"]

) Observe que o caminho deve ser absoluto, não relativo.

-g Use informações de depuração. Observe que você precisa disso durante a última fase de compilação de
bitcode para JavaScript, ou então iremos removê-lo por padrão em -O1 e acima. No
-O0, os números das linhas serão mostrados no código gerado. No -O1 e acima, o
o otimizador remove esses comentários. Esta bandeira, entretanto, tem o efeito de
desabilitar qualquer coisa que cause mutilação ou minimização do nome (fechamento ou o
registrar a passagem).

--matrizes digitadas
0: matrizes não digitadas 1: matrizes paralelas 2: matrizes compartilhadas (semelhantes a C)
(Padrão)

--llvm-opções
0: Sem otimizações LLVM (padrão em -O0) 1: -O1 Otimizações LLVM (padrão em
-O1) 2: -O2 Otimizações LLVM 3: -O3 Otimizações LLVM (padrão em -O2+)

--llvm-lto
0: Sem LLVM LTO (padrão em -O2 e abaixo) 1: LLVM LTO (padrão em -O3) Nota: Se
Otimizações LLVM não são executadas (veja --llvm-opções), defini-lo como 1 não tem efeito.

--fecho
0: Sem compilador de encerramento (padrão em -O2 e abaixo) 1: Execute o compilador de encerramento. Esse
reduz bastante o tamanho do código e pode, em alguns casos, aumentar a velocidade do tempo de execução (embora
o oposto também pode ocorrer). Observe que leva tempo para ser executado e pode exigir algum
mudanças no código. Isso é executado por padrão em -O3.

No modo asm.js, o encerramento só será usado no código 'shell' em torno do compilado
código (o código compilado será processado pelo minificador asm.js personalizado).

Nota: Se o compilador de encerramento atingir uma falta de memória, tente ajustar JAVA_HEAP_SIZE em
o ambiente (por exemplo, para 4096 m para 4 GB).

--js-transformação
será chamado no código gerado antes de ser otimizado. Isso permite que você
modificar o JavaScript, por exemplo, adicionando algum código ou removendo algum código, de uma forma
que essas modificações serão otimizadas junto com o código gerado
devidamente. será chamado com o nome do arquivo do código gerado como um
parâmetro; para modificar o código, você pode ler os dados originais e, em seguida, anexá-los
ou sobrescrevê-lo com os dados modificados. é interpretado como um espaço separado
lista de argumentos, por exemplo, de "python processor.py" causará um python
script a ser executado.

--pré-js
Um arquivo cujo conteúdo é adicionado antes do código gerado. Isso é feito * antes *
otimização, portanto, será minimizado adequadamente se o compilador de encerramento for executado.

--post-js
Um arquivo cujo conteúdo é adicionado após o código gerado. Isso é feito * antes de *
otimização, portanto, será minimizado adequadamente se o compilador de encerramento for executado.

--arquivo incorporado
Um arquivo para incorporar ao JavaScript gerado. O código compilado será capaz de
acesse o arquivo no diretório atual com o mesmo nome fornecido aqui. Então se
Você faz --arquivo incorporado dir / arquivo.dat, então (1) dir / arquivo.dat deve existir em relação a
onde você executa emcc, e (2) seu código compilado será capaz de encontrar o arquivo por
lendo o mesmo caminho, dir / file.dat. Se um diretório é passado aqui, todo o seu
o conteúdo será incorporado.

--preload-arquivo
Um arquivo para pré-carregar antes de executar o código compilado de forma assíncrona. De outra forma
semelhante ao --arquivo incorporado, exceto que esta opção só é relevante ao gerar
HTML (usa XHRs binários assíncronos) ou JS que será usado em uma página da web. Se
um diretório é passado aqui, todo o seu conteúdo será pré-carregado. Arquivos pré-carregados
são armazenados em nomedoarquivo.data, onde nomedoarquivo.html é o arquivo principal que você está compilando
para. Para executar seu código, você precisará de .html e .data.

emcc executa tools / file_packager.py para fazer o empacotamento real de incorporado e
arquivos pré-carregados. Você mesmo pode executar o compactador de arquivos se quiser, consulte os documentos
dentro desse arquivo. Você deve então colocar a saída do gerenciador de arquivos em um emcc
--pré-js, para que seja executado antes de seu código principal compilado (ou execute-o antes em
alguma outra maneira).

--compressão
Compacte o código compilado e os arquivos incorporados / pré-carregados. devia ser um
triplo,

, ,

onde native_encoder é um executável nativo que compacta stdin em stdout (o
interface mais simples possível), js_decoder é um arquivo JavaScript que implementa um
decodificador, e js_name é o nome da função a ser chamada no arquivo de decodificador (que
deve receber uma matriz / matriz digitada e retornar uma matriz / matriz digitada. Compressão
só funciona ao gerar HTML. Quando a compressão está ligada, todos os arquivos especificados para serem
pré-carregados são compactados em um grande arquivo, que recebe o mesmo nome do
saída HTML, mas com sufixo .data.compress

--minificar
0: não reduza o espaço em branco do JavaScript gerado (padrão em -O0, -O1, ou se
-g é usado)

1: Minimize o JavaScript gerado

espaço em branco (padrão em -O2+, assumindo -g não é usado)

--dividir
Divide o arquivo javascript resultante em partes para facilitar a depuração. Esta opção
só funciona se o Javascript for gerado (alvo -o .js). Arquivos com função
as declarações devem ser carregadas antes do arquivo principal na execução.

Sem a opção "-g":

Cria arquivos com declarações de funções até o tamanho fornecido com o sufixo
"_functions.partxxx.js" e um arquivo principal com o sufixo ".js".

Com a opção "-g":

Recria a estrutura de diretório dos arquivos de origem C e armazena a função
declarações em seus respectivos arquivos C com o sufixo ".js". Se tal arquivo
excede o tamanho fornecido, os arquivos com o sufixo ".partxxx.js" são criados. O principal
O arquivo reside no diretório base e tem o sufixo ".js".

--ligar Compila o código-fonte usando a abordagem de vinculação "embind", que conecta C / C ++
e JS.

--ignore-link dinâmico Normalmente emcc tratará o link dinâmico como
vinculação estática, vinculando no código da biblioteca dinâmica. Isso falha se o
mesma biblioteca dinâmica está vinculada mais de uma vez. Com esta opção, o link dinâmico
é ignorado, o que permite que o sistema de construção prossiga sem erros. No entanto, você
precisará se vincular manualmente às bibliotecas compartilhadas mais tarde.

--arquivo shell
O nome do caminho para um arquivo HTML esqueleto usado ao gerar saída HTML. A concha
arquivo usado precisa ter este token dentro dele: {{{SCRIPT_CODE}}} Observe que este
argumento é ignorado se um destino diferente de HTML for especificado usando o -o opção.

--js-biblioteca
Uma biblioteca JavaScript para usar além daquelas em src / library_ * da Emscripten

-v Ativa a saída detalhada. Isto vai passar -v para Clang, e também habilitar EMCC_DEBUG para
detalha as operações do emcc

--jcache
Use um cache JavaScript. Isso é desabilitado por padrão. Quando ativado, o emcc irá armazenar
os resultados da compilação em um cache e verifique o cache ao compilar mais tarde,
algo como o que o ccache faz. Isso permite compilações incrementais - onde você está
compilar um grande programa, mas apenas modificar uma pequena parte dele - para ser muito mais rápido
(ao custo de mais IO de disco para acessos de cache). Observe que você precisa habilitar
--jcache para carregar e salvar dados, então você deve habilitá-lo em uma compilação completa
para que uma compilação incremental posterior (onde você também a habilite) seja acelerada.

O cache funciona separadamente em 4 partes da compilação: 'pre' que é tipos e global
variáveis; essa informação é então alimentada em 'funções' que são as funções (que
paralelizamos) e, em seguida, 'postar', que adiciona informações finais com base no
funções (por exemplo, precisamos do código de suporte long64). Finalmente, 'jsfuncs' são
Otimizações em nível de JavaScript. Cada uma das 4 partes pode ser armazenada em cache separadamente, mas
observe que eles podem afetar um ao outro: Se você recompilar um único arquivo C ++ que
muda uma variável global - por exemplo, adiciona, remove ou modifica uma variável global, digamos
adicionando um printf ou adicionando um timestamp de tempo de compilação, então 'pre' não pode ser
carregado do cache. E uma vez que a saída de 'pre é enviada para' funcs 'e' post ', eles
será invalidado também, e apenas 'jsfuncs' será armazenado em cache. Portanto, evite modificar
globais para permitir que o cache funcione totalmente.

Para contornar o problema mencionado no parágrafo anterior, você pode usar

emscripten_jcache_printf

ao adicionar printfs de depuração ao seu código. Essa função é especialmente pré-processada para
que ele não cria uma string constante global para seu primeiro argumento. Ver
emscripten.h para mais detalhes. Observe em particular que você já precisa ter um
chamar essa função em seu código * antes * de adicionar um e fazer um
construir, de modo que adicionar uma referência externa (também uma propriedade global) não
invalidar tudo.

Observe que você deve usar -g durante o estágio de vinculação (bitcode para JS), para jcache para
trabalho (caso contrário, a minimização de JS pode confundi-lo).

--Limpar cache
Limpa manualmente o cache de bibliotecas de sistema emscripten compiladas (libc ++,
libc ++ abi, libc). Normalmente, isso é feito automaticamente, mas se você atualizar o llvm
no local (em vez de ter um diretório diferente para uma nova versão), o cache
mecanismo pode ficar confuso. Limpar o cache pode corrigir problemas estranhos relacionados a
incompatibilidades de cache, como falha do clang ao vincular aos arquivos da biblioteca. Isso também
limpa outros dados armazenados em cache, como o jcache e o relooper inicializado. Depois de
o cache for limpo, este processo será encerrado.

--save-bc PATH
Ao compilar para JavaScript ou HTML, esta opção salvará uma cópia do código de bits
para o caminho especificado. O bitcode incluirá todos os arquivos sendo vinculados, incluindo
bibliotecas padrão e após quaisquer otimizações de tempo de link (se houver).

--memory-init-file
Se ativado, geramos um arquivo de inicialização de memória separado. Isso é mais eficiente
do que armazenar os dados de inicialização da memória embutidos no JavaScript como texto.
(o padrão é desligado)

O arquivo de destino, se especificado (-o ), define o que será gerado:

.js
JavaScript

.html
HTML com JavaScript incorporado

.bc
LLVM bitcode (padrão)

.o
LLVM bitcode (igual a .bc)

(Observe que se --memory-init-file é usado, então, além de um arquivo .js ou .html que é
gerado, um arquivo .mem também aparecerá.)

A -c opção (que diz ao gcc para não executar o vinculador) fará com que o bitcode LLVM seja
gerado, pois o emcc só gera JavaScript no estágio final de vinculação da construção.

Os arquivos de entrada podem ser arquivos de código-fonte que o Clang pode manipular (C ou C ++), LLVM
bitcode em formato binário ou arquivos de montagem LLVM em formato legível por humanos.

emcc é afetado por várias variáveis ​​de ambiente. Para obter detalhes, consulte a fonte do emcc
(pesquise 'os.environ').

emcc: destinos suportados: llvm bitcode, javascript, NOT elf (autoconf gosta de ver elf
acima para habilitar o suporte a objetos compartilhados)

DIREITOS AUTORAIS

Copyright © 2013 dos autores do Emscripten (ver AUTHORS.txt) Este é um código-fonte livre e aberto
software sob a licença do MIT. NÃO há garantia; nem mesmo para COMERCIALIZAÇÃO ou
ADEQUAÇÃO A UMA FINALIDADE ESPECÍFICA.

Use emcc online usando serviços onworks.net