makepp_build_cache_control - Online na nuvem

PROGRAMA:

NOME

makepp_build_cache - Como configurar e usar caches de construção

DESCRIÇÃO

C: limpar \ limpo,
crio, M: makepp_build_cache_control,
mpbcc, S: exposição,
stats

A construir esconderijo é um diretório contendo cópias de alvos anteriores que já fazem o makepp
construído. Quando o makepp é solicitado a construir um novo alvo, ele vê se já o construiu
em outro lugar sob as mesmas condições e, em caso afirmativo, simplesmente vincule ou copie-o em vez de
reconstruindo-o.

Um cache de compilação pode ser útil nas seguintes circunstâncias:

· Você está trabalhando em um programa e o compila de maneira otimizada. Então você descobre um bug,
e recompilar tudo no modo de depuração. Você encontra o bug e agora deseja
recompile-o no modo otimizado. A maioria dos arquivos será idêntica. Se você usou um
construir cache em todas as suas compilações, o makepp irá simplesmente puxar os arquivos inalterados
fora do cache de construção em vez de recompilá-los.

Uma situação semelhante é se você normalmente trabalha em uma arquitetura, mas muda brevemente para
uma arquitetura diferente, e então você muda de volta. Se os arquivos antigos ainda estiverem no
construir cache, makepp não terá que recompilar nada.

· Você retirou várias cópias de um programa específico de seu controle de versão
sistema e fizeram alterações diferentes em cada hierarquia de diretório. (Por exemplo, você é
resolvendo bugs diferentes em hierarquias de diretório diferentes.) A maioria dos arquivos serão
idênticos nas duas hierarquias de diretório. Se você construir ambos com um cache de construção, o
construir na segunda hierarquia de diretório será capaz de simplesmente copiar os arquivos do
construir cache em vez de recompilar arquivos iguais.

· Você tem vários desenvolvedores trabalhando no mesmo conjunto de fontes. Cada desenvolvedor é
fazendo alterações, mas a maioria dos arquivos são idênticos entre os desenvolvedores. Se todo o
desenvolvedores compartilham um cache de construção, então, se a construção de um desenvolvedor compilar um arquivo, qualquer
construção de outro desenvolvedor que tem que compilar o arquivo idêntico (com o mesmo
inclui, etc.) pode apenas copiar o arquivo em cache em vez de executar novamente a compilação.

Um cache de compilação pode ajudar se todas as condições a seguir forem verdadeiras:

· Você tem bastante espaço em disco. Normalmente, o makepp vai acabar armazenando em cache muitas cópias de
cada arquivo que está mudando, porque não tem ideia de quais serão realmente usados.
Você pode desligar o cache de construção para certos arquivos, mas se o cache de construção vai
ser útil, provavelmente terá que conter muitos arquivos.

· Seus arquivos demoram muito mais para serem compilados do que para serem copiados. Se o cache de construção estiver no
mesmo sistema de arquivos, o makepp tentará usar links físicos em vez de copiar o arquivo.
O makepp precisa vincular ou copiar o arquivo para o cache quando o arquivo é compilado e, em seguida,
tem que vincular ou copiar o arquivo do cache quando for necessário novamente. Além disso,
há uma pequena sobrecarga envolvida na verificação se o arquivo necessário está realmente em
o cache de compilação e copiando as informações de compilação sobre o arquivo, bem como o arquivo
si.

Você pode descobrir, por exemplo, que usar um cache de construção não vale a pena para compilar muito
pequenos módulos. É quase certo que não vale a pena que os comandos façam um estático
biblioteca (um arquivo, libxyz.a), exceto se você usar links para economizar espaço em disco.

· Há uma grande probabilidade de que alguns arquivos sejam necessários novamente em outro
compilação. Se você está compilando apenas um pedaço de software uma vez, os caches de construção podem
apenas desacelerar as coisas.

Usar um cache de construção requer um pouco de configuração e trabalho de manutenção. Por favor não
tente usar um cache de construção até entender como eles funcionam, como criá-los e como
impedi-los de crescer continuamente e consumir todo o espaço em disco disponível em seu
sistema.

Como funciona o dobrador de carta de canal a construir esconderijo funciona
Se você habilitar um cache de construção, cada vez que um arquivo é construído, o makepp armazena uma cópia em um
construir cache. O nome do arquivo é uma chave que é um hash das somas de verificação de todos os
entradas e o comando de construção e a arquitetura. Da próxima vez que o makepp quiser reconstruir
o arquivo, ele vê se há um arquivo com as mesmas somas de verificação já no cache de compilação.
Nesse caso, o arquivo é copiado do cache de construção.

Para eficiência, se o cache de construção estiver localizado no mesmo sistema de arquivos que a construção, makepp
não irá realmente copiar o arquivo; em vez disso, ele criará um link físico. Isso é mais rápido e
não usa nenhum espaço extra em disco. Da mesma forma, quando makepp deseja puxar um arquivo de
o cache de compilação, ele usará um link físico, se possível, ou o copiará, se necessário.

AVISO: makepp nunca exclui arquivos de um cache de construção, a menos que seja explicitamente solicitado.
Isso significa que seus caches de construção continuarão a crescer sem limites, a menos que você limpe
atualizá-los periodicamente (veja detalhes abaixo).

Construção caches e repositórios

Construir caches e repositórios (veja makepp_repositories) pode resolver problemas semelhantes. Para
algumas situações, um repositório é mais apropriado, enquanto para outras, um cache de construção é mais
apropriado.

Você também pode combinar os dois. Se você tem uma estrutura de diretório enorme com muitos
fontes, das quais você não quer que todo desenvolvedor tenha uma cópia, então você pode fornecê-los
como um repositório. Os arquivos produzidos, com várias opções de depuração e assim por diante, podem ser
gerenciado de forma mais flexível por meio de um cache de construção.

As principais diferenças entre um cache de construção e um repositório são:

· Um cache de construção só pode armazenar arquivos criados pelo procedimento de construção. Um repositório pode
também tem arquivos de origem original.

· Arquivos em um repositório devem não mudar durante o curso de uma construção. Um cache de construção
não tem tal restrição.

· Os arquivos em um repositório devem estar presentes na mesma posição relativa que os arquivos em
o diretório de construção. Por exemplo, se o makepp precisa do arquivo subdir1 / subdir2 / xyz.abc, então isso
só olha para repository_root / subdir1 / subdir2 / xyz.abc. Os arquivos em um cache de construção têm
perderam todas as informações de hierarquia de diretório e são pesquisadas apenas com base nas entradas
e o comando que era necessário para produzi-los.

· Os arquivos em um repositório são vinculados a seus novos locais na construção
diretórios. Os arquivos em um cache de construção são copiados ou vinculados a seus novos
Localizações. Se for necessária uma cópia, um repositório certamente será mais rápido.

· Caches de construção custam um pouco de tempo para colocar arquivos neles. Um repositório não tem
qualquer custo extra (para a execução atual, ou seja, havia, é claro, o custo de criação
de antemão), mas geralmente requer um planejamento um pouco mais antecipado.

Em geral, um repositório é mais útil se você tiver uma única construção central que deseja
todos os desenvolvedores de onde obter os arquivos. Um cache de construção é o que você deseja se tiver um
sistema descentralizado onde um desenvolvedor deve pegar emprestado os arquivos compilados de qualquer outro
desenvolvedor.

Ambos os caches de construção e repositórios podem ajudar com construções variantes. Por exemplo, se você quiser
para compilar todas as suas fontes otimizadas, novamente com depuração, e novamente otimizadas,
você pode evitar recompilar todos os arquivos otimizados novamente usando um repositório ou um
construir cache. Para fazer isso com um repositório, você tem que pensar no futuro e dizer explicitamente
makepp para usar um repositório para a compilação de depuração, ou então ele apagará seu
compilação inicial otimizada. Com um cache de construção, makepp vai em frente e elimina o
compilação inicial otimizada, mas pode recuperá-la rapidamente.

Construção esconderijo agrupamento
Um grupo é um acoplamento fraco de caches de construção. É solto no sentido de que o makepp não
lidar com isso, para não retardar o gerenciamento do cache de construção. Para se beneficiar disso você
tem que usar o utilitário offline. Notavelmente, o comando "limpar" também executa o
replicação. Se você fornecer um critério de limpeza irreal, como "--mtime = + 1000", não
a limpeza ocorre, apenas a replicação.

O agrupamento permite compartilhar arquivos com mais pessoas, especialmente se você tiver seus caches de construção
nos discos dos desenvolvedores, para se beneficiar de links físicos, o que economiza tempo de envio e
espaço em disco. O hard linking sozinho, entretanto, é restrito aos benefícios por disco.

Com o agrupamento, o arquivo será replicado em algum momento após o makepp submetê-lo ao
construir cache. Isso significa que o arquivo será criado apenas uma vez para todos os discos juntos.

Em sistemas de arquivos que permitem links físicos para links simbólicos - o que parece restrito a
Linux e Solaris - o arquivo também estará fisicamente presente em apenas um disco.
Além disso, ele permanece em cada disco em que foi criado antes de você replicar, mas apenas como
desde que esteja em uso nesses discos. Neste cenário, com links simbólicos, você pode escolher um ou
mais sistemas de arquivos nos quais você prefere que seus arquivos estejam fisicamente. Esteja ciente que
arquivos construídos com sucesso podem ficar indisponíveis, se o disco em que estão fisicamente for
desligada. A reconstrução vai remediar isso, e o impacto pode ser diminuído espalhando o
arquivos em vários discos preferidos.

A replicação tem vários usos interessantes:

NFS (possível com cópia também)
Você tem um servidor NFS central que fornece o cache de compilação preferido. Cada máquina
e o disco do desenvolvedor tem um cache de construção local para envio rápido. Você quer montar de volta
todos os discos do desenvolvedor para o servidor NFS, e realizar a replicação e limpeza
centralmente, ou você replica localmente em cada máquina cliente NFS, tratando apenas a parte
do grupo visível lá.

Disco inseguro (possível com cópia também)
Se você compilar em um disco RAM (espero editar suas fontes em um repositório em um cofre
disco), você pode fazer com que os discos seguros sejam os preferidos. Então a replicação irá
migre os arquivos para os discos seguros, onde eles sobrevivem a uma reinicialização. Após cada reinicialização
você terá que recriar o cache de construção do disco RAM e adicioná-lo ao grupo (o que irá
dar um aviso, inofensivo neste caso, porque os outros membros do grupo ainda se lembram
isto).

Disco completo (links físicos apenas para links simbólicos)
Se um de seus discos estiver notoriamente cheio, você pode fazer os caches de construção em todos os
outros discos sejam preferidos. Dessa forma, a replicação irá migrar os arquivos para longe do
disco cheio, aleatoriamente para qualquer um dos outros.

Como funciona o dobrador de carta de canal para usar a construir esconderijo
Como funciona o dobrador de carta de canal para dizer makepp para usar da construir esconderijo

Uma vez que o cache de construção foi criado, ele agora está disponível para makepp. Existem vários
opções que você pode especificar durante a criação; consulte "Como gerenciar um cache de construção" para obter detalhes.

Um cache de construção é especificado com a opção de linha de comando --build-cache, com o
instrução build_cache dentro de um makefile ou com o modificador de regra: build_cache.

As maneiras mais úteis que descobri até agora de trabalhar com caches de construção são:

· Defina o caminho do cache de construção na variável de ambiente MAKEPPFLAGS, assim (primeiro
variante para Korn Shell ou bash, segundo para csh):

export MAKEPPFLAGS = - build-cache = / path / to / build / cache
setenv MAKEPPFLAGS --build-cache = / path / to / build / cache

Agora, cada compilação que você executar sempre usará esse cache de compilação, e você não precisa
modificar qualquer outra coisa.

· Especifique o cache de construção em seus makefiles com uma linha como esta:

BUILD_CACHE: = / caminho / para / build_cache
build_cache $ (BUILD_CACHE)

Você tem que colocar isso em todos os makefiles que usam um cache de compilação (ou em um include comum
arquivo que todos os makefiles usam). Ou coloque isso em seu Arquivo RootMakepp:

BUILD_CACHE: = / caminho / para / build_cache
global build_cache $ (BUILD_CACHE)

Em uma máquina multiusuário, você pode configurar um cache de construção por disco doméstico para levar
vantagem de links. Você pode achar mais conveniente usar uma declaração como esta:

build_cache $ (find_upwards our_build_cache)

que pesquisa para cima a partir do diretório atual no sistema de arquivos atual até que ele
encontra um diretório chamado nosso_build_cache. Esta pode ser a mesma afirmação para todos
usuários e ainda apontam individualmente para o cache em seu disco.

O Solaris 10 pode fazer algumas remontagens sofisticadas de diretórios pessoais. Sua casa vai
aparentemente é um ponto de montagem próprio, chamado /casa/$ LOGNAME, quando na verdade está ligado
um dos / export / home * discos junto com os de outros usuários. Porque não é
realmente um sistema de arquivos separado, os links ainda funcionam. Mas você não pode pesquisar para cima.
Em vez disso, você pode fazer:

BUILD_CACHE: = $ {makeperl }

Construção caches e assinaturas

O makepp procura arquivos no cache de construção de acordo com suas assinaturas. Se você estiver usando
o método de assinatura padrão (data + tamanho do arquivo), o makepp só puxará os arquivos do
construir cache se a data do arquivo dos arquivos de entrada for idêntica. Dependendo de como sua construção
funciona, as datas dos arquivos podem nunca ser idênticas. Por exemplo, se você fizer check-out de arquivos em
duas hierarquias de diretório diferentes, as datas dos arquivos são provavelmente a hora que você verificou
os arquivos de saída, não a hora em que os arquivos foram registrados (dependendo, é claro, do seu
software de controle de versão).

O que você provavelmente deseja é retirar os arquivos do cache de compilação se o arquivo conteúdo e guarante que os mesmos estão
idênticos, independentemente da data. Se for esse o caso, você deve usar algum tipo de
uma assinatura baseada em conteúdo. Makepp faz isso por padrão para compilações C e C ++, mas
usa datas de arquivo para qualquer outro tipo de arquivo (por exemplo, arquivos de objeto ou quaisquer outros arquivos em
o processo de construção não é especificamente reconhecido como uma fonte C ou arquivo de inclusão). Se você quiser
outros tipos de arquivos para trabalhar com o cache de construção (ou seja, se você quiser que funcione com
qualquer coisa diferente de comandos de compilação C / C ++), então você poderia colocar uma declaração como esta
em algum lugar próximo ao topo do seu makefile:

assinatura md5

para forçar o makepp a usar assinaturas com base no conteúdo dos arquivos ao invés de sua data.

Como funciona o dobrador de carta de canal não para esconderijo certo arquivos

Pode haver certos arquivos que você sabe que nunca desejará armazenar em cache. Por exemplo, se
você incorpora um carimbo de data em um arquivo, você sabe que nunca irá, em nenhuma circunstância
deseja obter uma cópia anterior do arquivo do cache de construção, porque o carimbo de data
é diferente. Neste caso, é apenas uma perda de tempo e espaço em disco copiá-lo para o
construir cache.

Ou você pode pensar que é altamente improvável que queira armazenar em cache o executável final.
Você pode querer armazenar em cache objetos individuais ou objetos compartilhados que fazem o
executável, mas muitas vezes é bastante improvável que você construa um exatamente idêntico
executável a partir de entradas idênticas. Novamente, neste caso, usar um cache de construção é um desperdício de
espaço em disco e tempo, portanto, faz sentido desativá-lo.

Às vezes, um arquivo pode ser extremamente rápido de gerar e é apenas um desperdício colocá-lo em
o cache de construção, pois pode ser gerado tão rapidamente quanto copiado. Você pode querer
desative seletivamente o armazenamento em cache desses arquivos.

Você pode desligar o cache de construção para regras específicas, especificando ": build_cache none" em
uma regra, como esta:

our_executable: dateStamp.o main.o * / *. so
: build_cache nenhum
$ (CC) $ (LDFLAGS) $ (entradas) -o $ (saída)

Este sinalizador significa que quaisquer saídas desta regra em particular nunca serão colocadas no
cache de construção e o makepp também nunca tentará retirá-los do cache de construção.

Como funciona o dobrador de carta de canal para gerencia a construir esconderijo
makepp_build_cache_control comando ...
mpbcc comando ...

makepp_build_cache_control, mpbcc é um utilitário que administra caches de construção para makepp.
O Quê makepp_build_cache_control faz é determinado pela primeira palavra de seu argumento.

Na verdade, este pequeno script é um wrapper para o seguinte comando, que você pode querer
chame diretamente em seus cron jobs, onde o caminho para "makeppbuiltin" pode ser necessário:

comando makeppbuiltin -MMpp :: BuildCacheControl ...

Você também pode usar esses comandos de um makefile após carregá-los, com um prefixo "&" - como
segue para o exemplo de "criar":

perl {use Mpp :: BuildCacheControl} # É um módulo Perl, então use ao invés de include.

meu_cache:
& create $ (CACHE_OPTIONS) $ (output) # Chama um builtin carregado.

build_cache $ (pré-construir my_cache)

Os comandos válidos, que também usam algumas das opções padrão descritas em
makepp_builtins, são:

crio [opção ...] caminho / para / cache ...
Cria os caches de construção com as opções fornecidas. As opções válidas são:

Opções padrão: "-A, --args-file, --arguments-file = filename, -v, --verbose"

-e grupo
--extend =grupo
--extend-group =grupo
Adicione o novo cache de construção ao "grupo". Este pode ter sido um único autônomo
construir cache até agora.

-f
--força
Isso permite criar o cache mesmo se caminho / para / cache já existia. Se fosse
um arquivo é excluído. Se fosse um diretório, ele é reutilizado, com qualquer
conteúdo que tinha.

-p
--preferido
Esta opção só é significativa se você tiver caches de construção no grupo, que permitem
difícil vincular a links simbólicos. Nesse caso, a limpeza irá migrar os membros para o
disco preferido. Você pode criar vários caches dentro de um grupo com esta opção, em
caso em que os arquivos serão migrados aleatoriamente para eles.

-s n1, n2, ...
--subdir-chars =n1, n2, ...
Controla quantos níveis de subdiretórios são criados para conter os arquivos em cache,
e quantos arquivos haverá em cada subdiretório. O primeiro n1 personagens do
nome do arquivo forma o nome do diretório de nível superior e os caracteres de n1 para n2 formulário
o nome do diretório de segundo nível e assim por diante.

Os arquivos no cache de construção são nomeados usando hashes MD5 de dados que o makepp usa, então
cada nome de arquivo tem 22 dígitos de base64 mais o nome do arquivo original. Se um cache de construção
o nome do arquivo é 0123456789abcdef012345_module.o, é realmente armazenado na construção
cache como 01/23/456789abcdef012345_module.o se você especificar "--subdir-chars 2,4".
Na verdade, "--subdir-chars 2,4" é o padrão, que é para um cache de construção gigante
de no máximo 4096 dirs com 416777216 subdiretórios. Mesmo "--subdir-chars 1,2" ou
"--subdir-chars 1" o levará muito longe. Em um sistema de arquivos otimizado para enormes
diretórios você pode até dizer "-s ''" ou "--subdir-chars =" para armazenar todos os arquivos em
o nível superior.

-m permanentes
--mode =permanentes
--access-permissions =permanentes
Especifica as permissões de acesso ao diretório quando os arquivos são adicionados à construção
cache. Se você quiser que outras pessoas coloquem arquivos em seu cache de construção, você deve fazer
é um grupo ou um mundo gravável. As permissões devem ser especificadas usando notação octal.

Como essas são permissões de diretório, se você conceder qualquer acesso, também deve conceder
execute o acesso, ou você obterá um monte de falhas estranhas. Ou seja, 0700 significa que
apenas este usuário pode ter acesso a este cache de construção. 0770 significa que este usuário e
qualquer um no grupo pode ter acesso de gravação ao cache de construção. 0777 significa que
qualquer um pode ter acesso ao cache de construção. Os dígitos octais sensíveis são 7
(escrever), 5 (ler) ou 0 (nenhum). 3 (escrever) ou 1 (ler) também é possível, permitindo
o cache a ser usado, mas não a ser navegado, ou seja, seria mais difícil para um
usuário malicioso para localizar nomes de arquivo para manipular.

Em um grupo de caches de construção, cada um tem seu próprio valor para isso, então você pode impor
diferentes permissões de gravação em diferentes discos.

Se você não especificar as permissões, suas permissões umask no momento da criação
aplicam-se durante todo o tempo de vida do cache de construção.

limpar [opção ...] / caminho / para / cache ...
Limpa o cache. O makepp nunca exclui arquivos do cache de construção; É com você
para deletar os arquivos com este comando. Para caches multiusuário, o sysop pode fazer isso.

Apenas os arquivos com uma contagem de links de 1 são excluídos (caso contrário, o arquivo não será
excluído fisicamente de qualquer maneira - você apenas retiraria o cache de um arquivo que alguém aparentemente está
ainda está interessado, então outra pessoa também pode estar). Os critérios que você fornece referem-se a
os arquivos em cache reais. Cada arquivo de informações de construção será excluído quando seu arquivo principal for.
Nenhum diretório vazio será deixado. Independentemente da contagem de links e das opções que você
dar, qualquer arquivo que não corresponda ao seu arquivo de informações de construção será excluído, se for mais antigo
do que uma margem de segurança de 10 minutos.

As opções a seguir usam uma especificação de tempo como argumento. As especificações de tempo começam com
um "+" significa há mais tempo, um "-" significa mais recentemente ou nada significa entre os
número que você dá, e mais um. Os números, que podem ser fracionários, são dias padrão.
Mas eles podem ser seguidos por uma das letras "w" (semanas), "d" (dias, o padrão),
"h" (horas), "m" (minutos) ou "s" (segundos). Observe que os dias são simplesmente 24 horas reais
ignorando qualquer mudança entre o verão e o inverno. Exemplos:

1 entre 24 e 48 horas atrás
24h entre 24 e 25 horas atrás
0.5d entre 12 e 36 horas atrás
1w entre 7 e 14 vezes 24 horas atrás
-2 menos de 48 horas atrás
+ 30m a mais de 30 minutos atrás

Todas as opções a seguir são combinadas com "e". Se você quiser vários conjuntos de
combinações com "ou", você deve chamar este comando repetidamente com diferentes conjuntos de
opções. Faça aqueles em que você espera mais exclusões primeiro, então os outros podem
seja mais rápido.

Opções padrão: "-A, --args-file, --arguments-file = filename, -v, --verbose"

-a especulação
--um tempo especulação
--tempo de acesso especulação
A última vez que o arquivo foi lido. Para um arquivo vinculado, isso pode acontecer a qualquer momento.
Caso contrário, esta é a última vez que o arquivo foi copiado. Em sistemas mal comportados
este também pode ser o último backup em fita ou a hora de criação do índice de pesquisa. Você poderia
tente excluir o cache de tais operações.

Alguns sistemas de arquivos não suportam o campo atime, e mesmo se o sistema de arquivos
faz, às vezes as pessoas desligam o tempo de acesso em seus sistemas de arquivos porque adiciona
muita E / S de disco extra que pode ser prejudicial em notebooks alimentados por bateria ou em
otimização da velocidade do disco. (Mas isso é potencialmente corrigível - consulte o
Comentário UTIME_ON_IMPORT em Mpp / BuildCache.pm.)

-b
--mistura
--grupos de mistura
Normalmente cada / caminho / para / cache você especificar tratará separadamente o grupo de construção
caches aos quais pertence. Cada grupo é tratado apenas uma vez, mesmo se você especificar
vários caminhos do mesmo grupo. Com esta opção, você mistura temporariamente todos
os grupos que você especificar em um grupo.

Fazer isso para limpar pode ter efeitos indesejáveis, se você puder fazer um link físico para links simbólicos,
porque pode migrar membros de um grupo para outro. Subseqüente não combinado
limpa, pode então limpá-los do grupo original prematuramente.

-c especulação
--ctime especulação
--change-time especulação
A hora da última alteração do inode do arquivo. Em uma situação de vinculação, isso poderia ser
o momento em que o último usuário recriou o arquivo de maneira diferente, cortando seu link para
o cache. Este também pode ser o tempo que a opção "--set-user" abaixo teve que
mudar o usuário. Em sistemas bem comportados, este também pode ser o momento em que o
último backup em fita ou criação de índice de pesquisa cobriu suas marcas redefinindo o
um tempo.

-m especulação
--m tempo especulação
- tempo de modificação especulação
A hora da última modificação do arquivo. Como explicado em outro lugar, é desencorajado
para que o makepp atualize um arquivo. Portanto, a última modificação geralmente será a hora
da criação. (Mas no futuro o makepp pode opcionalmente atualizar o mtime quando
deletando arquivos. Isso é para que os links em sistemas de arquivos ou cópias atime-less possam ser
monitorados.)

-g grupo
--newgrp =grupo
--new-group =grupo
Defina o id de grupo real e efetivo para o grupo (nome ou numérico). Apenas root pode ser
capaz de fazer isso. Isso é necessário quando você usa caches de construção agrupados, e você
fornecer acesso de gravação aos caches com base na id do grupo. Normalmente isso não será
grupo do root e, portanto, a replicação criaria diretórios não graváveis ​​sem este
opção.

Esta opção tem o nome do utilitário equivalente "newgrp" que, infelizmente, não pode ser facilmente
ser usado em tarefas "cron" ou configurações semelhantes.

-i
--build-info
--build-info-verificar
Verifique se as informações de construção correspondem ao membro. Este teste é bastante caro, então
você pode considerar não dar essa opção durante o dia.

-l
--symlink-verificar
- verificação de link simbólico
Esta opção faz "limpar" ler todos os links simbólicos que não tenham nenhum disco externo
links para verificar se ele aponta para o membro desejado. Como isso é um pouco
caro, sugere-se fazer isso apenas à noite.

-M especulação
--in-mtime especulação
--incoming-modificação-time especulação
A hora da última modificação para arquivos no diretório de entrada. Este diretório é
usado para arquivos temporários com nomes específicos de processo que podem ser escritos sem
acesso simultâneo e, em seguida, renomeado na parte ativa do cache atomicamente.
Os arquivos normalmente ficam aqui apenas pelo tempo necessário para gravá-los, mas eles podem
tornam-se órfãos se o processo que os está escrevendo terminar de forma anormal antes de
pode removê-los. Esta parte do cache é limpa primeiro, porque o link conta
na parte ativa do cache pode ser afetada indevidamente por arquivos órfãos.

A especificação de tempo para "--incoming-modify-time" deve começar com "+" e os padrões
para "+ 2h" (arquivos com pelo menos 2 horas são considerados órfãos).

-w
- dias úteis
Isso influencia a contagem das opções de tempo. Os fins de semana são ignorados, como se eles
não estavam lá. Uma exceção é se você der essa opção em um fim de semana. Então isso
fim de semana conta normalmente. Então você pode usá-lo em cronjobs executados a partir de terça-feira
até sábado. O horário de verão é ignorado. Então, fins de semana de verão podem ir a partir de sábado
1h00 a 1h00 de segunda-feira, ou fins de semana de inverno do hemisfério sul de sexta-feira às 23h00
Domingo 23:00 ou o quanto o seu fuso horário muda a hora. Feriados também são
não é levado em conta.

-p código perl
--perl =código perl
--predicate =código perl
TODO: adapte esta descrição às mudanças do grupo!

Este é o canivete do oficial suíço. o código perl é chamado no contexto escalar uma vez
para cada entrada de cache (ou seja, excluindo diretórios e arquivos metainfo). Isto é
chamado em uma função "Arquivo :: Encontrar" "desejada", então veja lá as variáveis ​​que você pode
usar. Um "lstat" foi executado, então você pode usar o manipulador de arquivos "_".

If código perl devolve "undef" é como se não estivesse aí, é o outro
as opções decidem. Se retornar verdadeiro, o arquivo será excluído. Se retornar falso, o
arquivo é retido.

-s especulação
--Tamanho especulação
A especificação do tamanho do arquivo funciona exatamente como as especificações de tempo, com "+" para
maior que ou "-" para menor que, exceto que as unidades devem ser "c" (bytes, o
padrão), "k" (kilobytes), "M" (megabytes) ou "G" (gigabytes).

-u usuário
--user =usuário
--set-user =usuário
Essa opção é muito diferente. Não diz quando excluir um arquivo. Em vez disso
aplica-se aos arquivos que não são excluídos. Observe que em muitos sistemas apenas root
tem permissão para definir o usuário de um arquivo. Veja em "Advertências ao trabalhar com construção
caches "por que você pode precisar mudar a propriedade para algum usuário neutro se você usar
cotas de disco.

Esta estratégia só funciona se você puder confiar que seus usuários não subverterão o build
cache para armazenar arquivos arbitrários (ou seja, não de desenvolvimento) além de sua cota de disco.
A propriedade do arquivo de metadados associado é mantida, então você sempre pode ver
quem armazenou um arquivo em cache. Se você precisar desta opção, pode ser necessário fornecer vários
vezes durante o dia.

Existem diferentes estratégias possíveis, dependendo de quanto espaço você tem e em
se o cache de construção contém arquivos vinculados ou se os usuários têm apenas cópias.
Várias estratégias podem ser combinadas, chamando-as uma após a outra ou em diferentes
vezes. O comando "show" destina-se a ajudá-lo a encontrar uma estratégia apropriada.

Uma execução noturna (de terça a sábado) pode especificar "--atime +2" (ou "--mtime"
se você não tiver o atime), excluindo todos os arquivos que ninguém leu por dois dias.

Se você usar links, também pode evitar o crescimento rápido e inútil que ocorre quando
mudanças sucessivas de cabeçalho, que nunca têm controle de versão, levam a muitos objetos
sendo rapidamente criado. Algo como uma execução horária com "--mtime = -2h --ctime = + 1h"
durante o dia vai pegar aqueles caras que o criador excluiu em menos de uma hora,
e ninguém mais quis desde então.

mostrar [opção ...] / caminho / para / cache ...
Este é um tipo de comando recursivo "ls -l" ou "stat", que mostra o dono original
também, para quando o proprietário do arquivo em cache for alterado e o arquivo de metadados
retém o proprietário original (de acordo com "clean --set-user"). Mostra os arquivos fornecidos, ou
tudo sob os diretórios fornecidos.

Os campos são, no padrão curto e na forma detalhada longa:

MODE, modo
O modo octal do arquivo em cache, que geralmente é como foi colocado, menos o
escrever bits.

EL, links ext
O número de links físicos externos que existem para todos os membros do grupo combinados.
Somente quando for 0, o arquivo estará qualificado para limpeza.

C, cópias (apenas para caches de construção agrupados)
O número de cópias do arquivo idêntico, em todos os caches de construção. Idealmente isso
é aquele em sistemas que permitem hard links para links simbólicos, mas isso pode
temporariamente impossível, enquanto houver links externos para mais de uma cópia
(nesse caso, perderíamos a contagem de links se o excluíssemos.

S, links simbólicos (apenas para caches de construção agrupados)
O número de links simbólicos entre caches de construção. Idealmente, este é o número de
construir caches menos um em sistemas que permitem hard linking para links simbólicos.
Mas, conforme explicado no campo anterior, pode haver mais cópias do que o necessário,
e, portanto, menos links.

UID O proprietário do arquivo em cache. Isso pode ser alterado com a opção "clean --user".

BI-UID
O proprietário do arquivo de informações de compilação. Isso não é alterado por limpar, permitindo ver
quem primeiro criou o arquivo.

TAMANHO
O tamanho (de uma cópia) em bytes.

atime, mtime, ctime
Na forma longa e detalhada, você obtém o tempo de acesso (leitura) ao arquivo, a modificação
tempo e o tempo de mudança de inode (por exemplo, quando algum usuário excluiu seu link externo para
o arquivo em cache). No formulário padrão curto, você obtém apenas uma das três vezes
em três colunas separadas:

AD, DM, CD
O dia da semana do acesso, modificação ou mudança de inode.

DATA, MATA, CDATA
A data de acesso, modificação ou mudança de inode.

ATIME, MTIME, CTIME
A hora do dia do acesso, modificação ou mudança de inode.

MEMBRO
O caminho completo do arquivo em cache, incluindo a chave, da raiz do cache.

Com "-v, --verbose" as informações mostradas para cada comando permitem que você obtenha um
impressão de quais opções dar ao comando "limpar". Os horários são mostrados em
forma legível, bem como o número de dias, horas ou minutos da idade deste arquivo
acabou de ultrapassar. Se você dobrar a opção, você adicionalmente obterá as informações para cada
membro do grupo.

Opções padrão: "-A, --args-file, --arguments-file = filename, -f, --force, -o,
--output = nome do arquivo, -O, --outfail, -v, --verbose "

-a
--um tempo
--tempo de acesso
Mostra a hora de acesso ao arquivo, em vez da hora de modificação do arquivo no modo não detalhado.

-b
--mistura
--grupos de mistura
Normalmente cada / caminho / para / cache você especificar tratará separadamente o grupo de construção
caches aos quais pertence. Cada grupo é tratado apenas uma vez, mesmo se você especificar
vários caminhos do mesmo grupo. Com esta opção, você mistura temporariamente todos
os grupos que você especificar em um grupo.

-c
--ctime
--change-time
Mostra o tempo de mudança das informações do inode, em vez do tempo de modificação do arquivo de forma não detalhada
modo.

-d
--deletável
Mostra apenas arquivos apagáveis, ou seja, aqueles com uma contagem de links externos de 0.

-p de cinto de segurança
--pattern =de cinto de segurança
padrão é um padrão de nome de arquivo de estilo bash (ou seja,?, *, [], {,,}) correspondido
nomes de membros após o sublinhado que os separa da chave.

-s Lista
--sort =Lista
No modo não detalhado, altere a ordem de classificação. A lista não diferencia maiúsculas de minúsculas
ordem separada por vírgulas ou espaços dos títulos das colunas. Existem dois casos especiais:
"membro" considera apenas os nomes após a chave, ou seja, os nomes dos arquivos como estão
fora do cache. E há um nome especial "idade", que agrupa qualquer
a data e a hora estão sendo mostradas. O padrão desta opção é "membro, idade".

Se você tiver um cache enorme, para o qual a classificação é insuportavelmente demorada ou precisa de mais
memória do que seus processos são permitidos, você pode pular a classificação, dando um vazio
Lista.

stats [opção ...] / caminho / para / cache ...
Isso gera várias tabelas de estatísticas sobre o conteúdo do cache de construção. Cada mesa
é dividido em três grupos de colunas. A primeira coluna varia para cada tabela e é o
título de linha. Os outros dois grupos pertencem à soma de TAMANHO de arquivos e número de ARQUIVOS
para esse título. Diretórios e arquivos de informações de construção não são contados, então este é um
um pouco menos para o tamanho do que o uso real do disco e cerca da metade para o número de arquivos.

Cada um dos dois últimos grupos consiste em três pares de colunas, uma coluna com um valor,
e um para a porcentagem do total que o valor representa. O primeiro par mostra
o tamanho dos arquivos ou o número de arquivos. Os outros dois pares mostram o
CUMULAÇÃOação, uma vez do menor para a maior e uma vez no sentido inverso.

As três primeiras tabelas, com uma primeira coluna de AD, CD or MD mostrar tempos de acesso, inode
horários de mudança ou horários de modificação agrupados por dias. Os dias são, na verdade, blocos de 24 horas
contando regressivamente a partir da hora de início do comando estatísticas. A linha "0" do primeiro
tabela irá, portanto, mostrar a soma dos tamanhos e o número de arquivos acessados ​​em menos de um dia
atrás. Se nenhum arquivo for acessado, não haverá a linha "0". Linha "1" na terceira
a tabela mostrará os arquivos modificados (ou seja, gravados no cache de construção) entre 24 e 48
horas atrás.

A próxima mesa, EL, mostra links externos, ou seja, de quantas árvores de construção compartilham um arquivo de
o cache de construção. Esta é uma medida de utilidade do cache de construção. Infelizmente, apenas
funciona quando os desenvolvedores têm um cache Buld em seu próprio disco, caso contrário, eles têm que copiar
que não deixa rastro global. Quanto mais conteúdo tiver maior contagem de links externos, o
maior o benefício do cache de construção.

A próxima mesa, novamente EL, mostra as mesmas informações que o anterior, mas ponderado
pelo número de links externos. Cada byte ou arquivo com uma contagem de links externos de um
conta como um. Mas se a contagem for dez, os valores são contados dez vezes. É por isso
os títulos mudam para *TAMANHO e *ARQUIVOS. Este é um valor hipotético, mostrando como
quanto uso de disco ou quantos arquivos haveria se as mesmas árvores de construção tivessem usado
nenhum cache de construção.

Mais uma mesa, C: S cópias para links simbólicos, pertence apenas a caches agrupados. Idealmente todos
os membros existem em uma cópia e um link simbólico a menos do que os caches no grupo.
Os links simbólicos permanecem "0" até que a limpeza seja replicada. Pode haver mais de uma cópia,
se várias pessoas criaram o arquivo idêntico antes de ser replicado, ou se
a replicação migrou o arquivo para um disco preferencial, mas o arquivo original ainda estava em
usar. Cópias supérfluas tornam-se links simbólicos quando a limpeza descobre que não têm mais
links externos.

Opções padrão: "-A, --args-file, --arguments-file = filename, -v, --verbose"

-h
--horas
Exiba as três primeiras tabelas com uma granularidade muito mais precisa. Os títulos das colunas
mudar para AH, CH or MH adequadamente.

-p de cinto de segurança
--pattern =de cinto de segurança
padrão é um padrão de nome de arquivo de estilo bash (ou seja,?, *, [], {,,}) correspondido
nomes de membros após o sublinhado que os separa da chave. Todas as estatísticas
são limitados a arquivos correspondentes.

Advertências trabalhar com construir caches
Os caches de construção não funcionarão bem nas seguintes circunstâncias:

· Se o comando que o makepp executa para construir um arquivo, na verdade apenas novidades o arquivo e
não o constrói novo, então você deve NÃO use um cache de construção. (Um exemplo é um
comando para atualizar um módulo em uma biblioteca estática (um arquivo ou um arquivo com um
extensão de .a) Conforme explicado no makepp_cookbook, em máquinas modernas é quase
sempre uma má ideia atualizar um arquivo - é melhor reconstruí-lo do zero
cada vez por uma variedade de razões. Este é mais um motivo para não atualizar um
arquivo.) O motivo é que, se o cache de construção estiver localizado no
mesmo sistema de arquivos, o makepp cria um link físico em vez de copiar o arquivo. Se você então
posteriormente modificar o arquivo, o arquivo que makepp tem no cache de compilação
realmente ser modificado, e você poderia estragar a compilação de outra pessoa.
Na prática, o makepp pode geralmente detectar que um arquivo foi modificado desde que foi
colocado no cache de construção e não vai usá-lo, mas às vezes pode não
detectar a modificação.

· Para .o arquivos isso pode estar um pouco errado, porque eles podem (dependendo do compilador
e nível de depuração) contêm o caminho para a fonte a partir da qual foram criados. Isso pode fazer
depuração difícil. O depurador pode fazer você editar a cópia do criador original do
fonte, ou pode nem mesmo encontrar o arquivo, se o criador não tiver mais uma cópia. Makepp
pode algum dia oferecer uma opção para corrigir o caminho, o que, claro, significará uma cópia,
em vez de um link eficiente.

· Qualquer outro arquivo que tenha um caminho codificado não deve ser colocado em um cache de construção
(se você compartilhar seu cache de construção entre várias hierarquias de diretório ou vários
desenvolvedores). Neste caso, o resultado de uma construção em um diretório diferente não é o
mesmo como se estivesse no mesmo diretório, então todo o conceito de cache de construção é
não aplicável. Tudo bem se você especificar o caminho do diretório na linha de comando, como
esta:

& echo prog_path = $ (PWD) -o $ (saída)

porque então a linha de comando será diferente e o makepp não puxará incorretamente o
arquivo fora do cache de construção. Mas se a linha de comando não for diferente, então
pode ser um problema. Por exemplo,

echo prog_path = `pwd`> $ (saída)

não funcionará corretamente.

· Ao usar links e com muitos desenvolvedores ativos do mesmo projeto no mesmo disco,
construir caches pode economizar muito espaço em disco. Mas, ao mesmo tempo, para usuários individuais
o oposto também pode ser verdadeiro:

Imagine que Chang é o primeiro a fazer uma construção completa. Chega Ching e recebe um link para
todos esses arquivos. Chang faz algumas mudanças fundamentais que fazem com que a maioria das coisas sejam
reconstruído. Ele os verifica, Chong os verifica e obtém links para o cache de construção.
Chang novamente faz alterações, levando a um terceiro conjunto de arquivos.

Neste cenário, não importa a estratégia de limpeza que você usa, nenhum arquivo será excluído,
porque eles ainda estão em uso. O problema é que todos eles pertencem a Chang,
o que pode fazê-lo atingir sua cota de disco, e não há nada que ele possa fazer sobre isso
a maioria dos sistemas. Veja o comando "clean --set-user" em "Como gerenciar um cache de compilação"
para saber como o administrador do sistema pode alterar os arquivos para um proprietário de cache sem cota.

· Se você estiver usando assinaturas de carimbo de data / hora / tamanho para cruzar o alvo e sua construção
info (o padrão), então é possível obter um alias de assinatura, em que não
os arquivos correspondentes não serão detectados. Por exemplo, o valor de informação de compilação MD5_SUM
pode não corresponder à soma de verificação MD5 do destino. Isso geralmente não é um problema, porque
em virtude do fato de que as chaves do cache de construção correspondem, o destino no cache de construção
é substituível pelo destino que teria correspondido ao arquivo de informações de construção.
No entanto, se você tiver ações de regra que dependem de informações de compilação, isso pode levá-lo
em apuros (então não faça isso). Se isso o preocupa, use o método --md5-check-bc
opção.

Concorrente Acesso
Os caches de construção precisam suportar acesso simultâneo, o que implica que a implementação deve
seja tolerante com as raças. Em particular, um arquivo pode envelhecer (ser excluído) entre o tempo
makepp decide importar um destino e a hora em que a importação é concluída.

Além disso, algumas pessoas usam caches de construção sobre NFS, o que não é necessariamente coerente. No
outras palavras, a ordem de criação e exclusão do arquivo pelo gravador em um host não
necessariamente corresponde à ordem vista por um leitor em outro host e, portanto, corridas não podes
ser resolvido prestando atenção especial à ordem das operações de arquivo. (Mas existe
geralmente um tempo limite de cache NFS de cerca de 1 minuto, o que garante que as gravações não levem
mais do que esse período de tempo para propagar a todos os leitores. Além disso, normalmente em
prática, pelo menos 99% das gravações são visíveis em todos os lugares dentro de 1 segundo.) Por causa disso,
devemos tolerar o caso em que o destino em cache e seu arquivo de informações de construção parecem não
corresponder. Além disso, há uma corrida peculiar que pode ocorrer quando um arquivo é
simultaneamente envelhecido e substituído, em que os arquivos não correspondem mesmo após o NFS
descargas de cache. Isso parece inevitável.

Use makepp_build_cache_control online usando serviços onworks.net