makepp_rules - Online na nuvem

PROGRAMA:

NOME

makepp_rules - Como dizer ao makepp para construir algo

DESCRIÇÃO

?: &,
-,
@, B: : build_cache,
: build_check, D: :Despacho, E: : env, I: "ignore_error",
:incluir, L: :última chance, M: maquiagem, N: "noecho", P: : analisador,
"perl", S: :assinatura

Uma regra é o que diz ao makepp como construir um arquivo ou uma classe de arquivos. Makepp suporta o
mesma sintaxe de regra que outras implementações de make, mais algumas adições próprias.

Uma regra tem o formato geral

target_expression: dependency_expression [: argumentos opcionais]
ações

A lista de destinos não pode conter nenhuma variável automática (exceto "$ (foreach)"). o
lista de dependências pode conter apenas variáveis ​​automáticas referentes ao destino (ou seja,
"$ (output)", "$ (outputs)" ou seus sinônimos). A ação pode conter qualquer
variáveis.

Se makepp decidir que a regra deve ser executada, cada linha da regra é executada
sequencialmente, e se algum retornar um status diferente de zero, o restante não será executado (e
makepp aborta com um erro, a menos que você especifique a opção "-k" na linha de comando.)
Cada ação deve ser apenas uma linha. Se uma ação for muito longa para escrever convenientemente em um
única linha, você pode dividi-la em várias linhas e colocar uma barra invertida para indicar que o
várias linhas devem ser combinadas em uma.

A fim de distinguir as ações da próxima regra, a ação deve ser recuada mais
do que a linha que contém os destinos e dependências. Ao contrário de outras implementações de
make, makepp realmente não se importa com quanto você recua ou se você usa caracteres de tabulação
em vez de espaços. Para manter a compatibilidade com versões anteriores com a marca tradicional, as regras
O makepp usa para decidir quando as ações terminam e a próxima regra começa são um pouco complicados:

· A primeira linha de ação deve ser indentada mais do que a linha que contém o alvo.

· Se uma linha for recuada por um caractere de tabulação ou 8 espaços ou mais, ela será considerada
uma linha de ação.

· Uma linha em branco ou uma linha de comentário com o caractere "#" na margem direita termina o
regra, a menos que a próxima linha não em branco seja indentada com mais de 8 espaços (ou mais de um
aba).

· Se uma linha é indentada tanto ou mais do que a primeira linha de ação, então é
considerada uma linha de ação adicional.

Existem alguns itens de ação especiais:

& Este símbolo deve ser seguido por um nome de comando e qualquer número de argumentos. Concha
sintaxe não é totalmente entendida aqui, apenas aspas simples e duplas e barra invertida
personagens dentro, como em todo makepp. O nome do comando leva a uma função
"c_nome" a ser chamado com as strings restantes como argumentos. Se tal função pode
não for encontrado, isso é idêntico a chamar "run" de um bloco "perl".

Isso permite chamar com eficiência um comando interno, fornecido por makefile ou externo.
O prefixo "&" foi escolhido porque é o invocador da função em Perl e porque
no início, é ilegal na Shell.

$ (ROOT) / incluir /%. H:% .h
& ln $ (entrada) $ (saída)

noecho
@ Normalmente, cada comando do shell é impresso à medida que é executado. No entanto, se a primeira palavra
da ação é "noecho" (ou se começar com o caractere "@"), o comando
não é impresso. Por exemplo,

% .o:% .cxx
noecho $ (LIBTOOL) --mode = compilar $ (CC) -c $ (entrada)

Isso significa que quando o comando libtool é executado, ele não é impresso. (Libtool
em si geralmente imprime o comando modificado que executa, por isso é redundante para
imprima-o duas vezes.)

ignore_error
- Normalmente, se o comando shell retornar um status diferente de zero, o makepp aborta porque
o comando falhou. No entanto, alguns programas definem incorretamente o status ao sair, ou
pode haver um erro que realmente não é fatal e não deve abortar todo o
compilação. Você pode fazer com que o makepp ignore o status de retorno especificando
"ignore_error" como a primeira palavra da linha de comando (ou "-" como o primeiro caractere).
Por exemplo,

$ (distribuição falsa):
ignore_error rm -r my_program - $ (VERSION) # Livre-se do lixo anterior.
& mkdir meu_programa - $ (VERSÃO)
& cp $ (ARQUIVOS) meu_programa - $ (VERSÃO)
tar cf meu_programa - $ (VERSÃO) .tar meu_programa - $ (VERSÃO)

Este comando cria um diretório, copia um monte de arquivos nele e, em seguida, coloca
tudo em um arquivo tar para distribuição. É uma boa ideia limpar o
conteúdo anterior do diretório, se houver algo lá anteriormente, e isso é
o que a primeira linha faz. O "rm" pode falhar, mas seu status de retorno é ignorado.

perl
makeperl
Este é essencialmente o mesmo que a instrução perl, mas é executado sempre que
executando a regra, não ao ler o makefile. A primeira variante é Perl simples
código, enquanto a segunda variante primeiro passa a instrução por meio da variável de estilo Make
expansão.

Para as duas possibilidades de colocar as cintas do corpo, veja a explicação em
"perl_perlcode" em makepp_statements. Observe que a terceira variante explicada lá
não faz sentido aqui, porque todas as linhas de ação devem ser recuadas. Você deve sinalizar
falha em declarações Perl, chamando "morrer".

Por regra, as instruções Perl são avaliadas atualmente em um subprocesso comum, exceto em
Janelas. Isso significa que eles têm apenas acesso de leitura a quaisquer variáveis ​​makefile. Isso é também
o processo que executa ações não-Perl. Então, chamar exec ou exit vai confundir
makepp. Mas isso pode mudar no futuro. Para uma maneira eficiente de chamar Perl
scripts, consulte o item anterior "&" ou "executar".

$ (versão falsa):
noecho perl {{# $ (target) & $ (VERSION) do Perl:
print "Este é" .f_target (). "$ VERSION \ n";
}}
echo Você pode misturar isso com comandos Shell
-makeperl {print "Este é $ (target) $ (VERSION) \ n"}

Existem vários tipos diferentes de regras, cada uma com finalidades diferentes.

Explícito Regras
alvo1 alvo2: dependência1 dependência2 ...
ações a serem realizadas

Esta sintaxe especifica que, a fim de tornar qualquer Target1 or Target2, todos os arquivos
dependência1, dependência2, etc., já deve ter sido feito. Então, as ações dadas são
executado pelo shell para fazer os alvos.

A primeira regra explícita em um arquivo é o destino padrão e é feita se você não especificar
quaisquer alvos na linha de comando.

Ao contrário dos programas tradicionais de make, makepp geralmente assume que uma invocação da ação
faz todos os destinos (a menos que não haja dependências). Por exemplo, uma invocação
do yacc cria os dois arquivos de saída para esta regra:

y.tab.c y.tab.h: parser.y
$ (YACC) -d parser.y

Observe que outras implementações do make não têm o conceito de um único comando
produzindo vários arquivos de saída e, portanto, quando você especifica vários destinos, eles
execute a regra uma vez por alvo. O makepp irá reverter para este comportamento se parecer
este é um makefile antigo. Especificamente, ele executará a regra uma vez por alvo,
em vez de apenas uma vez no geral, se todas as afirmações a seguir forem verdadeiras:

· A ação da regra menciona a variável automática $ @. (Os sinônimos "$ (saída)" ou
"$ (target)" não aciona este comportamento.)

· A ação da regra não menciona a variável automática "$ (saídas)" (ou seu sinônimo
"$ (alvos)").

· Esta não é uma regra padrão e não existe uma cláusula foreach.

Por exemplo,

todas as instalações de teste:
para subdir em $ (SUBDIRS); faça cd $$ subdir && $ (MAKE) $ @; CD ..; feito

é um idioma comum em makefiles, e makepp o suporta. (Observe que você nunca deve usar
make recursivo em quaisquer novos makefiles que você escrever - use a instrução "load_makefile", ou
carregamento implícito de makefile em vez disso.)

Se você quiser que a mesma regra seja executada uma vez para cada alvo (por exemplo, porque os alvos
têm comandos semelhantes), é preferível usar uma regra de padrão (veja abaixo) ou um
cláusula "foreach". Por exemplo, se com um programa make tradicional, você escreveria:

abcd:
do_something para construir $ @> $ @

no makepp, você provavelmente gostaria de escrever assim:

$ (foreach):: foreach abcd
faça_something para construir $ (output)> $ (output)

Falso tem como alvo

A falso alvo é um destino que nunca existirá realmente no sistema de arquivos; é apenas um
forma de fazer o makepp construir alguns alvos e possivelmente executar alguns comandos adicionais.

Um alvo falso típico é "tudo", que geralmente é usado para causar tudo o que pode ser
construído para ser construído, assim:

todos: prog1 prog2 subdir / prog3 subdir2 / libmine.a
@ & echo "Tudo pronto!"

Se você digitar "makepp all", ou se você colocar all como o primeiro destino explícito em seu makefile
(o que é típico) e apenas digite "makepp", então fará com que todas as dependências sejam
construído, então ele irá imprimir "Tudo pronto!". Neste ponto, o makepp irá procurar o arquivo ./tudo
e descobrirá que ele não existe. Ele vai reclamar em voz alta.

Para evitar que o makepp espere o arquivo ./tudo para sair, você precisa dizer que é um
alvo falso. Basta colocar uma linha como a seguinte no seu makefile (não faz diferença
Onde):

.PHONY: todos

Uma alternativa equivalente que às vezes é mais conveniente é usar o "$ (falso)"
função, assim:

$ (todos falsos): prog1 prog2 subdir / prog3 subdir2 / libmine.a

Alvos falsos em um makefile podem se referir a alvos falsos em outro makefile. Isto é
geralmente feito com o alvo "limpo", como este:

# Makefile de nível superior:
# muitas regras e outras coisas aqui
# ....
$ (falso limpo): subdir1 / clean subdir2 / clean
& rm -fm meu_programa

Então, nos subdiretórios, os makefiles podem ser lidos assim:

# Makefile em um subdiretório
# ...
$ (falso limpo):
& rm -fm $ (curinga * .o * .a)

Mas hoje em dia você usaria o comando "makeppclean", em vez de um alvo limpo.

Curingas

É seguro especificar curingas na lista de dependências. Caracteres curinga não correspondem apenas a arquivos
que existem, mas arquivos que podem ser criados de acordo com as regras do makefile. Por exemplo,
para construir uma biblioteca de todos os arquivos .o em um diretório, você pode escrever isto:

libmine.a: * .o
& rm -f $ (saída)
ar cr $ (saída) $ (entradas)

Isso funcionará mesmo que nenhum dos arquivos ".o" tenha sido criado ainda, porque makepp's
curingas correspondem a arquivos que ainda não existem, mas podem ser construídos. Isso vai até pegar
arquivos cuja regra é descoberta posteriormente (no mesmo makefile, ou um ainda não lido). Nisso
último ponto difere da função "curinga", que se limita às regras conhecidas,
pois deve retornar seu resultado quando for expandido.

Makepp suporta todos os curingas usuais do shell ("*", "?" E "[]"). Também tem um
curinga "**" que corresponde a qualquer número de diretórios intermediários. (Esta ideia foi roubada
de zsh.) Por exemplo, "** / *. c" corresponde a todos os .c arquivos em toda a árvore de origem.
"objects / ** / *. o" corresponde a todos os .o arquivos contidos em qualquer lugar do subdiretório objetos
ou qualquer um de seus subdiretórios ou qualquer um de seus subdiretórios. O curinga "**" não
siga os links virtuais para diretórios em qualquer nível. Ele também nunca retornará alvos falsos.

Os curingas do Makepp irão ignorar os arquivos ou diretórios que existem, mas não podem ser lidos. Depois de
todos, esses arquivos não podem ser usados ​​no processo de construção de qualquer maneira. Colocar arquivos ilegíveis em um
diretório é principalmente útil para inibir a importação automática de um determinado arquivo de um
repositório.

A afirmação inicial era de que isso é seguro. Isso ocorre no sentido de que funciona se
os arquivos já existem ou precisam ser compilados primeiro. No entanto, não é seguro no sentido
que ainda irá corresponder aos arquivos que foram construídos pelo makepp, mas não tem mais uma regra (por exemplo
você removeu o .c arquivo, mas o .o arquivo ainda está lá.) Para evitar isso, use o
opção "--rm-stale".

padrão regras
Uma regra de padrão é uma regra aplicada com base em algum padrão textual. Isso é usado para
aplique a mesma regra a uma classe inteira de arquivos. A sintaxe é a mesma do GNU make
regras de padrão:

% .o:% .c
$ (CC) -c $ (entrada) -o $ (saída)

Isso diz que qualquer arquivo no diretório atual que corresponda a "* .c" pode ser convertido para
o arquivo .o correspondente usando o comando fornecido.

Observe que várias dependências de padrão podem ser fornecidas. Por exemplo, se o seu xyz.o lima
depende do correspondente xyz.cpp arquivo, e também em um arquivo chamado moc_xyz.cflags qual
contém as opções do compilador, isso pode ser expresso com:

% .o:% .cpp% .cflags
$ (CXX) `cat $ (stem) .cflags` -c $ (entradas) -o $ (saída)

Você também pode ter vários alvos de padrão. Por exemplo,

% .tab.h% .tab.c:% .y
yacc -d $ (entrada)
& mv y.tab.h $ (radical) .tab.h
& mv y.tab.c $ (radical) .tab.c

Normalmente, as regras de padrão procuram apenas arquivos nos diretórios atuais. Você pode forçar
para pesquisar no diretório atual e em todos os diretórios abaixo dele, definindo

makepp_percent_subdirs: = 1

antes da primeira regra de padrão em seu makefile ou na linha de comando, por exemplo.

Há uma diferença clara entre "%" e o caractere curinga "*", embora ambos correspondam a qualquer
string: o curinga retorna uma lista de arquivos que é completamente usada naquele ponto. Então
isso depende de tudo .o arquivos compiláveis ​​aqui:

prog: * .o
$ (LD) $ (LDFLAGS) $ (entradas) -o $ (saída)

Isso não poderia ser alcançado substituindo "*" por "%", porque o último é para um por um
correspondência de entrada para saída, produzindo internamente uma regra para cada haste correspondida.

Estático de cinto de segurança regras
Uma regra de padrão estático é uma regra de padrão aplicada apenas a um conjunto limitado de arquivos:

$ (SPECIAL_MODULES) .o:% .o:% .cpp
$ (CXX) -c $ (entrada) -o $ (saída)

Isso diz que a regra de padrão se aplica apenas aos arquivos em "$ (SPECIAL_MODULES) .o".

Isso é principalmente para compatibilidade com GNU make; regras foreach (veja abaixo) são mais
maneira poderosa de fazer a mesma coisa.

Para cada regras
A sintaxe da regra de padrão acima é poderosa o suficiente para suportar quase todas as compilações, mas
ocasionalmente é necessário fazer algo mais complicado. Makepp oferece mais
sintaxe poderosa: a cláusula ": foreach" para a regra.

target_expression: dependency_expression: foreach file-list
ações

O tipo mais simples de regra foreach é apenas uma regra de padrão cuja aplicação é restrita
a uma lista específica de arquivos. Por exemplo, suponha que você tenha uma regra de padrão que diz
makepp como compilar tudo .c arquivos. No entanto, você tem uma lista de .c arquivos para os quais você
Quer fazer algo diferente. Você poderia fazer algo assim:

# Esta é a regra que se aplica a tudo:
% .o:% .c
$ (CC) $ (CFLAGS) -c $ (entrada) -o $ (saída)

% .o:% .c: foreach $ (SPECIAL_MODULES)
$ (CC) $ (SPECIAL_CFLAGS) -c $ (entrada) -o $ (saída)

Um uso ainda mais poderoso das regras foreach aproveita o fato de que a variável
"$ (foreach)" é definido por sua vez para cada arquivo correspondente à lista de arquivos e ao destino e
expressões de dependência são avaliadas. A lista de arquivos pode conter curingas, e estes
corresponder até mesmo aos arquivos que ainda não existem, mas que podem ser construídos (ver "Caracteres curinga" em
makepp_rules).

Esta é uma sintaxe complicada, mas extremamente flexível, porque a variável "$ (foreach)"
pode aparecer de qualquer maneira na expressão. Primeiro, observe que as regras de padrão são, na verdade, um
caso especial de regras foreach; a regra padrão

% .o:% .c
$ (CC) $ (CFLAGS) -c $ (entrada) -o $ (saída)

é exatamente equivalente a:

$ (patsubst% .c,% .o, $ (foreach)): $ (foreach): foreach * .c
$ (CC) $ (CFLAGS) -c $ (entrada) -o $ (saída)

(Na verdade, é convertido para aproximadamente isso internamente.)

Como um exemplo de como você usaria uma cláusula ": foreach" onde uma regra de padrão não é
suficiente, suponha que você tenha algum .c arquivos que são construídos usando algum tipo de pré-processador
que leva como arquivos de entrada com um .k extensão. Você quer compilá-los .c arquivos com um
conjunto de opções de compilação diferente do usual .c arquivos que são fontes comuns
arquivos. Você poderia fazer algo assim:

# Regra para arquivos .c comuns:
% .o:% .c
$ (CC) $ (CFLAGS) -c $ (entrada) -o $ (saída)

# Regra para criar arquivos .c a partir de arquivos .k:
% .c:% .k
$ (pré-processador) $ (entrada)> $ (saída)

# Regras especiais de construção para arquivos .c que são feitos de arquivos .k:
$ (foreach:%. k =%. o): $ (foreach:%. c =%. k): foreach * .k
$ (CC) $ (SPECIAL_CFLAGS) -c $ (entrada) -o $ (saída)

(Isso usa a sintaxe de referência de substituição um pouco mais concisa em vez de chamar
"patsubst" explicitamente.)

Observe que se tudo o que você deseja fazer é alterar o valor de uma variável ("CFLAGS" neste
caso) às vezes é mais conveniente usar variáveis ​​específicas do destino.

Legado sufixo regras
Para compatibilidade com versões anteriores, makepp suporta as regras de sufixo do estilo antigo.

.suffix1.suffix2:
ações

é equivalente a

% .suffix2:% .suffix1
ações

mas muito mais difícil de lembrar. (Qual sufixo vem primeiro?) Normalmente, uma regra aparecerá
em um makefile legado como este:

.co:
$ (CC) $ (CFLAGS) -c $ *. C -o $ *. O

que é exatamente equivalente a

% .o:% .c
$ (CC) $ (CFLAGS) -c $ (entrada) -o $ (saída)

Conflitante regras
Quando há mais de uma maneira de fazer um arquivo, o makepp usa um procedimento simples para
determinar qual regra usar.

· É um erro ter regras explícitas conflitantes para a construção de um arquivo.

· As regras de padrão e as regras de foreach com curingas nunca substituem as regras explícitas. Assim
regras explícitas podem ser usadas para especificar exceções para regras de padrão. (Observe que simplesmente
usar uma cláusula ": foreach" não torna algo uma regra de padrão. Deve ter um
curinga (como "*" ou "?") como parte do nome do arquivo na cláusula ": foreach". Se for
apenas uma lista explícita de arquivos, ela é tratada como uma regra explícita para cada um desses
arquivos.)

· Quando regras de padrões conflitantes vêm de diferentes makefiles, regras de "mais próximo"
makefiles sobrescrevem regras de makefiles "mais distantes". "Mais próximo" significa que o makefile
está localizado mais próximo do destino na hierarquia do diretório (ou seja, o nome do arquivo do
destino relativo ao diretório a partir do qual o makefile é executado é mais curto). Se este
não distingue os makefiles, então a regra do makefile que é carregado
o mais recente é usado.

Isso significa que você pode especificar uma regra de padrão que se aplica a todos os arquivos em seu
árvore de diretório inteira apenas no makefile de nível superior, mas então você pode substituí-lo em
um makefile de nível inferior. Por exemplo, seu makefile de nível superior pode conter:

% .o:% .c: foreach ** / *. c
$ (CC) $ (CFLAGS) -c $ (entrada) -o $ (saída)

e você poderia ter um makefile em um dos subdiretórios que diz:

% .o:% .c
$ (CC) $ (SPECIAL_CFLAGS) -c $ (entrada) -o $ (saída)

· Regras de padrão que têm uma cadeia de inferência mais curta são preferidas em relação a outro padrão
as regras. Por exemplo, se você tivesse as seguintes regras (com base em um exemplo do
Kernel do Linux):

% .s:% .c
$ (CC) -s $ (entrada) -o $ (saída)

% .o:% .s
$ (AS) $ (entrada) -o $ (saída)

% .o:% .c
$ (CC) -c $ (entrada) -o $ (saída)

Se precisarmos construir "xyz.o", podemos construir o arquivo intermediário ".s" e então
executar isso por meio do montador usando as duas primeiras regras, ou poderíamos ir diretamente para um
Arquivo ".o" usando a última regra. A última regra é preferida porque há menos
etapas na cadeia de inferência (um em vez de dois).

· As regras de padrão posteriores em um makefile substituem as regras de padrão anteriores. (Isto é
para trás do GNU make.) Isso significa que você deve colocar suas regras mais gerais
mais cedo, e suas regras mais específicas mais tarde. Por exemplo,

% .o:% .c # Regra geral de compilação.
açao

especial _%. o: especial _%. c # Regra especial para arquivos com um
ação diferente # prefixo "especial_".

Regra opções
Às vezes é necessário fornecer opções adicionais para modificar a forma como o makepp executa o
regra. Essas opções são especificadas como "valor do nome da opção", na linha que contém
as dependências ou na próxima linha.

Fornecer as opções em linhas separadas pode possibilitar que você use o mesmo
makefile com makepp e um make tradicional. Por exemplo,

alvo: dependências
: assinatura target_newer
ações

funcionará bem com uma marca Unix tradicional, porque interpreta a linha ": assinatura"
como um comando shell e um comando que começa com dois pontos não faz nada.

: build_cache / caminho / para / construir / cache
alvo: dependências
: build_cache / put / cache / files / over / there
ações

Especifica o caminho para um cache de construção a ser usado para arquivos produzidos por esta regra. Esse
substitui o efeito da instrução "build_cache" ou do comando "--build-cache"
opção de linha, se houver, para esta regra. Veja makepp_build_cache para detalhes sobre a construção
caches.

Se você especificar "nenhum" em vez de um caminho, você desativa o cache de compilação para este
regra particular. Isso pode ser útil para evitar o desperdício de espaço em disco em arquivos que você
sei que não são úteis para armazenar em cache, porque você tem certeza de que nunca serão
reutilizados ou porque são construídos tão rápido que não vale a pena armazená-los em cache.

: build_check build_check_method
alvo: dependências
: build_check target_newer
ações

Isso diz ao makepp qual algoritmo usar para decidir se os alvos precisam ser reconstruídos.
Veja makepp_build_check para mais detalhes. Isso substitui o efeito do
declaração "build_check" ou a opção de linha de comando "--build-check-method", se houver, para
Esta regra.

: env VARIÁVEL ...
Adicione uma dependência nos valores das variáveis ​​de ambiente nomeadas. Se algum deles
diferem da construção anterior, então os alvos são considerados desatualizados, se o
método build_check assim dita. (Todos os métodos de verificação de compilação integrados, exceto para
target_newer respeite isso.)

VARIABLE pode ter o formato "nome do arquivo em PATH_VARIABLE" (entre aspas), caso em que o
destinos são considerados desatualizados se o primeiro diretório do delimitado por dois pontos
o valor de PATH_VARIABLE no qual o nome do arquivo existe é diferente da última construção.
Isso pode ser usado para evitar a reconstrução dos alvos quando PATH_VARIABLE muda em um
maneira irrelevante.

:Despacho comando ...
Envolva cada ação do shell (mas não ações Perl nem comandos Perl) em um "sh -c '...'"
e prefixe-o com command, mas assuma que o alvo não depende do comando.
Isso é útil se você deseja enviar ações para um sistema de fila de trabalhos, mas o resultado é
assumido ser independente dos parâmetros de enfileiramento, bem como se o enfileiramento
sistema é usado em tudo.

:incluir arquivo_ou_padrão
A regra varia dependendo do compilador:

% .o:% .c
: inclui% .d: assinatura C
gcc -MD -c...

% .o:% .c
: incluir% .u: assinatura C # IBM usa um sufixo diferente
xlc -M -c...

sub dependify {# Transforme a conversa da Microsoft em um formato útil
s / \ $ / \ $ \ $ / g;
s / (Nota: incluindo arquivo: *)? (. +?) \ r? \ n / $ 1? "'$ 2'": "'" .f_output (). "':" / E;
}
% .o:% .c
: inclui% .d: assinatura C
cl -showIncludes -c ...> $ (stem) .d
& sed & dependify -o + <$ (radical) .d

Alguns compiladores (Intel's icc, assim como gcc acima, ou IBM's xlc) podem produzir dependência
arquivos em tempo real. Isto é, enquanto eles compilam, eles escrevem um makefile que o makepp pode
incluir. A vantagem sobre o scanner do makepp é que ele tem garantia de 100%
correto, de onde podemos apenas chegar perto.

Esta opção aproveita isso de uma maneira especial: Se o arquivo não estiver presente, ou seja,
normalmente, na primeira construção, ocorre a varredura normal. Mas se o arquivo estiver presente, não
a varredura ocorre (é por isso que especificamos uma assinatura inteligente acima - não a varredura de quedas
de volta ao padrão idiota de timestamp e tamanho). Em vez disso, inclui o arquivo, antes
executando a regra. Depois de executar a regra com sucesso, ele esquece tudo o que
ler pela primeira vez, visto que o arquivo pode estar desatualizado. Em vez disso, lê
o arquivo novamente, se ele mudou, para ter informações de compilação atualizadas.

AVISO: isso é inerentemente não confiável. O arquivo de dependência é produzido pelo próprio
regra da qual é uma dependência. Por outro lado, o compilador sabe sobre todos
são subinclusões internas, que o makepp geralmente ignora. Esta é uma confiabilidade
vantagem apenas para o caso em que um patch do compilador corrige apenas os subincluídos. o
O preço é que o makepp acaba vendo muitos mais arquivos, o que leva tempo.

Há um problema quando você remove uma instrução "#include" e o arquivo correspondente:
Ele ainda será mencionado no arquivo de dependência da última vez, quando foi
precisava. Nesse caso, você deve editar o arquivo de dependência para remover a dependência
que não é mais realizável.

Este recurso não pode ser usado com um cache de construção porque buscar um arquivo de lá
requer saber tudo sobre o arquivo. Mas um arquivo de dependência depende daqueles
arquivos que o makepp aprende lendo. Essa dependência circular não é normalmente
possível em um sistema de construção confiável. Esta é uma exceção porque após a reconstrução
e relendo um arquivo de dependência tudo está correto novamente.

Se você construir em seus repositórios, makepp irá pegar o arquivo de dependência do
1º repositório que contém um. Isso é diferente de outros arquivos, onde leva o primeiro
com a assinatura esperada. Isso é melhor do que para construir caches, onde por falta de
assinatura, ele nem consegue encontrar o arquivo.

:última chance
Habilite uma regra aberta, como

% .foo foo% .bar:: last_chance
& echo $ @ -o $ @
& cp $ (saídas)

Como uma regra como essa pode gerar um número essencialmente infinito de alvos,
um destino desta regra não corresponderá a uma função $ (curinga) ou regra de padrão, a menos
outra coisa já instanciou a regra referenciando o alvo especificamente.
Além disso, se "--rm-stale" for especificado, então um destino que sobrou de um anterior
A execução do makepp parecerá desatualizada se a única maneira de construí-lo for por meio de uma regra last_chance
que ainda não foi instanciado para o alvo, o que é um comportamento desejável porque
a construção irá falhar de forma mais consistente quando se baseia erroneamente em um caractere curinga para
coincidir com os alvos de uma execução anterior.

A opção ": last_chance" tem como objetivo chamar a atenção para o comportamento especial do
regra em relação aos curingas correspondentes.

: analisador analisador
Isso diz ao makepp como analisar o comando para detectar (incluir) arquivos. Usualmente,
makepp adivinha como fazer isto baseado nas palavras do próprio comando (veja
makepp_scanning para detalhes). No entanto, se o makepp errar, você pode querer
indique explicitamente o analisador, assim:

% .o:% .abc
: analisador c_compilation
ação aqui

Isso faz com que o makepp execute a mesma análise e verificação que faz para C / C ++
construir comandos, mesmo que não reconheça a ação como uma compilação C.

O analisador padrão depende do comando. Se você não especificar uma opção ": parser",
então, a primeira palavra de cada comando é examinada. Por exemplo, para uma compilação ou link
comando, makepp usará o analisador "c_compilation"; ou se o comando se parece com o
Variante GNU, "gcc_compilation". Se nenhum analisador for encontrado, ele usa o analisador "nenhum". Para
mais detalhes sobre isso, ou se você deseja escrever seu próprio analisador ou alterar o do makepp
analisadores padrão, consulte makepp_scanning.

Observe que isso se aplica a todos os comandos da regra, que podem não ser o que você deseja:

% .o:% .c: analisador c-compilação
@echo 'Building $ (output)'
@funny_cc...

Isso também interpretará "echo" como um compilador e deduzirá seu argumento 'Construindo
mymodule.o 'como uma dependência implícita. Isso levará à reclamação de que
não sabe como construir tal arquivo. Neste caso, você estaria melhor com
"register_parser". Lá você encontra uma explicação de como analisador pode ser dado como um
classname ou como um nome de função.

:assinatura método_de_assinatura
alvo: dependências
: assinatura md5
ações

Isso diz ao makepp qual algoritmo usar para determinar se as dependências foram alteradas.
Veja makepp_signatures para mais detalhes. Métodos de assinatura que estão incluídos com o
distribuição makepp são "simples", "md5", "C" ou "c_compilation_md5", e
"shared_object". Isso substitui qualquer método de assinatura especificado com "-m" ou
opções de linha de comando "--signature-method" ou com a instrução "signature".

Destaque caracteres
Makepp pode suportar nomes de arquivos que possuem caracteres especiais como dois pontos ou um espaço.
Suponha, por exemplo, que você deseja criar um arquivo chamado "a: thing" a partir do arquivo "b: thing".
Você não pode escrever a regra desta forma:

a: thing: b: thing # Este é um erro de sintaxe
& cat $ (entrada) -o $ (saída)

porque o makepp não saberá quais pontos separam os alvos das dependências e quais são
parte dos nomes dos arquivos. Em vez disso, simplesmente coloque o nome entre aspas, assim:

"a: coisa": "b: coisa"
& cat $ (entrada) -o $ (saída)

Agora, a regra é inequívoca.

A sintaxe de citação do Makepp é bastante semelhante à do shell. Você pode, por exemplo, usar um único
aspas em vez de aspas duplas, ou você pode escapar de caracteres especiais com uma barra invertida:

a \: coisa: 'b: coisa'
& cat $ (entrada) -o $ (saída)

Suponha, por exemplo, que seu nome de arquivo seja "'"!; \ $ ". Agora, por que você deseja esse nome de arquivo
Não sei, mas aqui estão várias maneiras de especificá-lo para makepp (e o shell):

\ '' "!; \ $$ '
"'\"!; \\ $$ "

Preste atenção em quando o makepp retira as aspas e quando o shell o faz. Makepp olha para
citações apenas nos seguintes casos:

· Na família de testes "ifeq"

· Antes e depois da regra dois pontos

· Em um comando embutido makepp

· Em uma função que pertence a arquivos

Ao contrário do shell, o makepp não expande aspas ao atribuí-las a uma variável. Assim
as seguintes regras são idênticas:

ARQUIVO = 'nome com espaços'
x: = $ (print $ (FILE)) # apenas para verificar se as aspas ainda estão lá
$ (FILE): # aspas em torno de um único arquivo removido pelo makepp
& echo hello -o $ (FILE) # cita o arquivo único removido pelo makepp
echo there >> $ (FILE) # aspas em torno de um único arquivo removido pelo Shell
'nome com espaços':
& echo olá -o'nome com espaços '
echo there >> '$ (output)' # aspas foram retiradas acima, adicione-as novamente

Observe que (ao contrário do Shell) variáveis ​​que começam com "$" são expandidas mesmo dentro de
citações. Os cifrões não podem ser protegidos por aspas ou barras invertidas. Para obter um literal
cifrão, use um cifrão duplo, por exemplo,

$ (todos falsos):
@ & echo Este é um cifrão: $$
@for val in abcd; faça echo $$ val; feito

Geralmente, você deve ser capaz de lidar com praticamente qualquer caractere especial citando-o
de algum modo. Isso inclui espaços, caracteres de controle, etc. No entanto, esteja ciente de que em
presente, a remoção de comentários do makepp é um tanto simplista e quaisquer caracteres "#"
precedidos de espaços em branco serão interpretados como comentários, independentemente de como sejam citados.

Quando um destino ou nome de dependência é colocado em uma variável automática como "$ (saída)", então
as aspas e quaisquer barras invertidas são removidas. Isso significa que se você quiser fazer referência ao
nome do arquivo nas ações, você provavelmente terá que citá-lo novamente, assim:

"um nome de arquivo com espaços":
echo "Conteúdos especiais"> "$ @"

Se você não colocar as aspas em torno de $ @, o shell verá o comando

echo "Conteúdos especiais"> um nome de arquivo com espaços

que escreve a string "Nome do arquivo de conteúdo especial com espaços" no arquivo chamado a.
Provavelmente não é isso que você deseja.

Use makepp_rules online usando serviços onworks.net