5. Iniciando a Compilação
Anterior |  | Próxima

## 5. Iniciando a Compilação

Várias compilações separadas para cada arquitetura - a combinação de `branchs` é suportada. Todos os dados privados para uma compilação (árvore de `ports`, árvore do `src`, pacotes, `distfiles`, arquivos de `log`, `bindist`, `Makefile`, etc) estão localizados sob ``${arch}`/`${branch}`/builds/`${buildid}``. Alternativamente, a última compilação pode ser referenciada sob o `buildid` `latest`, e a anterior a esta é chamada `previous`.

Novas compilações são clonadas a partir da `latest`, o que é rápido, uma vez que ele usa ZFS.

### 5.1. Os `Scripts` `dopackages`

Os `scripts` `scripts/dopackages` são usados para executar as compilações.

#### 5.1.1. Código base antigo

Para o código base antigo, os mais úteis são:

- `dopackages.7` - Executa a compilação para a série 7.X

- `dopackages.7-exp` - Executa a compilação para a série 7.X com `patches` experimentais (`branch` 7-exp)

- `dopackages.8` - Executa a compilação para a série 8.X.

- `dopackages.8-exp` - Executa a compilação para a série 8.X com `patches` experimentais (`branch` 8-exp)

- `dopackages.9` - Executa a compilação para a série 9.X.

- `dopackages.9-exp` - Executa a compilação para a série 9.X com `patches` experimentais (`branch` 9-exp)

- `dopackages.10` - Executa a compilação para a série 10.X.

- `dopackages.10-exp` - Executa a compilação para a série 10.X com `patches` experimentais (`branch` 10-exp)

Esses são `wrappers` para o `dopackages` e todos são `links` simbólicos para `dopackages.wrapper`. `Wrappers` de `scripts` para um novo `branch` podem ser criados com `links` simbólicos `dopackages.${branch}` para `dopackages.wrapper`. Esses `scripts` tem uma série de argumentos. Por exemplo:

`dopackages.7 `${arch}` `${buildid}` `[-options]``

#### 5.1.2. Novo código base

Você pode usar o `dopackages.wrapper` diretamente, ao invés dos `links` simbólicos. Por exemplo:

`dopackages.wrapper `${arch}` `${branch}` `${buildid}` `[-options]``

#### 5.1.3. Para ambos os códigos base

Frequentemente você usará `latest` como valor para o `buildid`.

`[-options]` pode ser nulo, uma ou mais, das opções seguintes:

- `-keep` - Não remove esta compilação no futuro, quando normalmente seria removido como parte do ciclo `latest` - `previous`. Não se esqueça de efetuar a limpeza manualmente quando ele não for mais necessário.

- `-nofinish` - Não executa o pós-processamento após finalizar a compilação. Isto é útil se você espera que a compilação precise ser reiniciada depois de concluída. Se você usar esta opção, não se esqueça de limpar os clientes quando você não precisar mais da compilação.

- `-finish` - Executa apenas o pós-processamento.

- `-nocleanup` - Por padrão, quando o estágio `-finish` da compilação é completado, os dados da compilação serão removidos dos clientes. Esta opção vai evitar a remoção dos dados.

- `-restart` - Reinicia uma compilação interrompida (ou não finalizada) a partir do começo. Os `Ports` que falharam na compilação anterior serão recompilados.

- `-continue` - Reinicia uma compilação interrompida (ou não finalizada). Os `Ports` que falharam na compilação anterior não serão recompilados.

- `-incremental` - Compara os campos importantes do novo `INDEX` com a versão anterior, remove pacotes e arquivos de `log` dos `ports` antigos que foram alterados, e recompila o resto. Isso reduz o tempo de compilação substancialmente, pois os `ports` inalterados não serão recompilados todas as vezes.

- `-cdrom` - O empacotamento desta compilação será usado em um CD-ROM, então os pacotes marcados como `NO_CDROM` e os `disfiles` deverão ser removidos no pós-processamento.

- `-nobuild` - executa todas as etapas do pré-processamento, mas não a compilação dos pacotes.

- `-noindex` - Não reconstrói o `INDEX` durante o pré-processamento.

- `-noduds` - Não reconstrói o arquivo `duds` (`ports` que nunca são compilados, como por exemplo, aqueles marcados com `IGNORE`, `NO_PACKAGE`, etc.) durante o pré-processamento.

- `-nochecksubdirs` - Não verifica o `SUBDIRS` para os `ports` que não estão ligados à compilação. (Apenas para o novo código base).

- `-trybroken` - Tenta compilar `ports` marcados como `BROKEN` (desativado por padrão, pois os `clusters` amd64/i386™ agora são suficientemente rápidos e quando fazem compilações incrementais eles gastam muito mais tempo do que o necessário para compilar tudo. Por outro lado, os outros `clusters` são bastante lentos, e seria um desperdício de tempo tentar compilar `ports` marcados como `BROKEN`).

  ### Nota:

  Com `-trybroken`, provavelmente você também vai querer usar `-fetch-original` (e, no novo código base, `-unlimited-errors`).

- `-nosrc` - Não atualiza a árvore do `src` a partir do `snapshot` do ZFS, mantendo a árvore da compilação anterior.

- `-srccvs` - Não atualiza a árvore do `src` a partir do `snapshot` do ZFS, em vez disso ela é atualizada com o `cvs update`.

- `-noports` - Não atualiza a árvore de `ports` a partir do `snapshot` do ZFS, mantendo a árvore da compilação anterior.

- `-portscvs` - Não atualiza a árvore de `ports` a partir do `snapshot` do ZFS, em vez disso ela é atualizada com o `cvs update`.

- `-norestr` - Não tenta compilar `ports` marcados como `RESTRICTED`.

- `-noplistcheck` - Não considera como erro `ports` deixarem arquivos para trás ao serem removidos.

- `-nodistfiles` - Não coleta os `distfiles` que passarem no `make checksum` para depois fazer o upload para o `ftp-master`.

- `-fetch-original` - Baixa o `distfile` a partir do `MASTER_SITES` original, em vez do `ftp-master`.

- `-unlimited-errors` (apenas no novo código base) - anula a verificação de limites do qmanager para compilações descontroladas. Você pode querer isso principalmente quando usar `-restart` em uma compilação que provavelmente vai falhar, ou talvez quando executar `-trybroken`. A A limitação é realizada por padrão.

A menos que você especifique `-restart`, `-continue`, ou `-finish`, os `links` simbólicos para as compilações existentes serão rotacionados. Isto é, o `link` simbólico para `previous` será removido; a compilação mais recente terá seu `link` modificado para `previous/`; e a nova compilação será criada e referenciada com um `link` em `latest/`.

Se a última compilação finalizou de forma limpa, você não precisa remover nada. Se ela foi interrompida, ou você usou a opção `-nocleanup`, você precisa limpar os clientes executando:

`build cleanup `${arch}` `${branch}` `${buildid}` -full`

Os diretórios `errors/`, `logs/`, `packages/`, e assim por diante, são limpos pelos `scripts`. Se você está com pouco espaço, também pode limpar o `ports/distfiles/`. Não altere o diretório `latest/`; ele é um link simbólico para o servidor web.

### Nota:

O `dosetupnodes` supostamente é executado pelo `script` `dopackages` no caso de `-restart`, mas pode ser uma boa idéia executá-lo manualmente e depois verificar se todos os clientes tem a carga de trabalho esperada. Algumas vezes `dosetupnode` não pode limpar uma compilação e você precisará fazer isso manualmente. (Isto é um defeito.)

Verifique se a compilação de pacotes para a arquitetura `${arch}` está executando como usuário ports-`${arch}` ou ele apresentará um grande número de erros.

### Nota:

Atualmente, a própria compilação de pacotes ocorre em duas fases idênticas. A razão para isso é que, algumas vezes, problemas temporários (por exemplo, falhas do NFS, sites FTP inalcançáveis, etc.) podem quebrar a compilação. Realizar o processo em duas fases é uma solução alternativa para esse tipo de problema.

Seja cuidadoso com `ports/Makefile` para não especificar qualquer diretório vazio. Isso é especialmente importante se você está realizando uma compilação com `patches` experimentais (-exp). Se o processo de compilação encontrar um diretório vazio, ambas as fases de compilação irão parar rapidamente, e um erro similar ao seguinte será adicionado para ``${arch}`/`${branch}`/make.[0|1]`:

`don't know how to make dns-all(continuing)`

Para corrigir este problema, simplesmente comente ou remova as entradas `SUBDIR` que apontam para subdiretórios vazios. Depois de feito isso, você pode reiniciar a compilação executando o comando `dopackages` adequado com a opção `-restart`.

### Nota:

Este problema também ocorre se você criar uma nova categoria com um `Makefile` sem entradas `SUBDIR`s nele. Isso é, provavelmente, um defeito.

Exemplo 6. Atualize a árvore i386-7 e faça uma compilação completa

`dopackages.7 i386 -nosrc -norestr -nofinish`

`dopackages.wrapper i386 7 -nosrc -norestr -nofinish`

Exemplo 7. Reinicie uma compilação para amd64-8 interrompida sem atualizar

`dopackages.8 amd64 -nosrc -noports -norestr -continue -noindex -noduds -nofinish`

`dopackages.wrapper amd64 8 -nosrc -noports -norestr -continue -noindex -noduds -nofinish`

Exemplo 8. Realize o pós-processamento de uma árvore sparc64-7 concluída

`dopackages.7 sparc64 -finish`

`dopackages.wrapper sparc64 7 -finish`

Dica: geralmente é melhor executar o comando `dopackages` dentro do `screen(1)`.

### 5.2. O comando `build`

Você pode precisar manipular os dados da compilação antes de inicia-la, especialmente para compilações experimentais. Isto é feito com o comando `build`. Aqui estão algumas opções úteis para criação:

- `build create `arch` `branch` [`newid`]` - Cria um `newid` (ou um `datestamp`, se não for especificado). Só é necessário quando da criação de um novo `branch` ou uma nova arquitetura. (TODO: documentar se `newid` deve ser especificado como `latest` no novo código base.)

- `build clone `arch` `branch` `oldid` [`newid`]` - Cria um clone do `oldid` para o `newid` (ou um `datestamp`, se não for especificado).

- `build srcupdate `arch` `branch` `buildid`` - Substitui a árvore `src` com um novo `snapshot` do ZFS. Não se esqueça de usar a opção `-nosrc` quando executar o `dopackages` mais tarde!

- `build portsupdate `arch` `branch` `buildid`` - Substitui a árvore de `ports` com um novo `snapshot` do ZFS. Não se esqueça de usar a opção `-noports` quando executar `dopackages` mais tarde!

### 5.3. Compilando um único pacote

Algumas vezes é necessário recompilar um único pacote a partir do conjunto de pacotes. Isso pode ser feito executando o seguinte comando:

``path`/qmanager/packagebuild `amd64` `7-exp` `20080904212103` `aclock-0.2.3_2.tbz``

Anterior |  | Próxima
4. Customizando Sua Compilação | Principal | 6. Anatomia de uma compilação

Este, e outros documentos, podem ser obtidos em ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Para perguntas sobre FreeBSD, leia a documentação antes de contatar <questions@FreeBSD.org>.
Para perguntas sobre esta documentação, envie e-mail para <doc@FreeBSD.org>.