Google Summer of Code – Última semana

Segundo o cronograma do Google Summer of Code, essa foi a última semana do programa, onde deveríamos parar de produzir código e nos concentrar em escrever a documentação, fazer testes, etc.


Logotipo vencedor de uma competição que o BRL-CAD realizou recentemente.

Disponibização do código-fonte

É interessante a política do BRL-CAD de prover o código das dependências junto com o código do aplicativo. Isso facilita bastante a vida do usuário, que não tem que ficar instalando dependências, principalmente aquelas que tem que compilar a partir do fonte, e nem se preocupar com compatibilidade de versões das bibliotecas. Além disso, é possível escolher quais das bibliotecas você quer usar do seu sistema e quais você quer que o BRL-CAD compile.

Ficou decidido então que eu ia criar um novo repositório no svn e subir lá todas as bibliotecas das quais a OSL necessita e também um script para compilá-las.

Embora a biblioteca OSL seja pequena, ela faz bastante uso de bibliotecas externas como: OpenEXR, Ilmbase, Open Image IO (que por sua vez depende da libpng, libjpeg, libtiff), LLVM e Boost. As duas últimas são relativamente grandes, a LLVM com ~250MB e a Boost ~500MB, o que torna problemático o upload no repositório.

A decisão tomada foi deixar a LLVM como responsabilidade do usuário e subir apenas as bibliotecas necessárias do boost. Como a Boost é composta de diversas outras bibliotecas modulares, existe uma ferramenta do próprio boost, chamada bcp, para selecionar apenas aquelas necessárias para a aplicação, incluindo também as dependências das próprias bibliotecas do boost.

Apanhei um pouco para compilar e usar a ferramenta, mas acabei conseguindo diminuir de ~500MB para cerca de 50MB!

Portabilidade de arquivos no SVN

Para que os arquivos carregados em um SVN funcionem de maneira transparente entre diversos sistemas, principalmente entre linux e windows, é preciso tomar certos cuidados, como por exemplo:

– Linux e windows usam diferentes caracteres como final de linha para arquivos de textos.
– Linux suporta links simbólicos e windows não
– Linux decide se um arquivo é executável através de permissões do arquivo, enquanto o windows usa a extensão do nome do arquivo para decidir.

Por isso é importante especificar se um arquivo é do tipo texto ou binário por exemplo. Para não ter que setar essa informação arquivo a arquivo, o svn usa as extensões dos mesmos para decidir que tipo de arquivo ele é. Para isso, ele especifica diversas possibilidades no arquivo config (em geral fica em .subversion/) através de padrões (geralmente *.extensão). Quando o nome do arquivo não casa com nenhum padrão, o svn pode ser configurado para não deixar commitar.

Um problema que eu vinha enfrentando é que o svn só dá esse erro na fase final de commit e nesse caso ele aborta o commit de todos os arquivos. Isso significa que dependendo do tamanho do código sendo adicionado, pode levar horas até eu perceber que o commit falhou e eu preciso especificar os tipos dos arquivos, quer adicionando um padrão no arquivo de configuração, quer manualmente, com o comando svn propset. Aí então tentar fazer o commit de todos os arquivos novamente.

Decidi fazer um script python que lê esse arquivo de configuração, lê todos os arquivos a serem adicionados e verifica quais deles não casam com nenhum padrão. Aí eu fico sabendo rapidamente quais arquivos precisam ter seu mime-type e/ou eol-style setados.

Dependência externa do SVN

Às vezes a estrutura de um código requer que façamos checkouts a partir de diferentes endereços de repositórios. Por exemplo, imagine que o diretório foo fique em http://algum.endereco.svn/foo. Porém, dentro desse diretório foo deve existir um pasta bar, mas ela fica em http://outro.endereco.svn/bar.

A princípio basta fazer checkout de foo e depois entrar em foo e fazer checkout de bar. Porém, exigir que o usuário saiba dessa estrutura é um complicador adicional. Para isso, existe a propriedade svn:externals, que especifica quais diretórios deverão ser puxados de endereços diferentes. No exemplo, podemos setar a propriedade de foo entrando nesse diretório e digitando:

svn propset svn:externals 'http://outro.endereco.svn bar' .

Aí, quando dermos checkout em http://algum.endereco.svn/foo, ele puxará o subdiretório bar em http://outro.endereco.svn/bar. Esse link contém uma explicação mais detalhada de como setar o svn:externals.

Tive que usar essa funcionalidade do svn pois duas bibliotecas que eu precisava prover (zlib e libpng), já são providas pelo BRL-CAD no repositório principal. Bastou eu fazer a ligação externa que agora as duas bibliotecas são baixadas junto com as outras dependências. Com isso não precisamos duplicar código no repositório e temos a garantia que as versões utilizadas dessas bibliotecas são as mesmas.

Tarefas restantes

Na parte de organização do código, só tratei de remover código comentado e excluir alguns arquivos do SVN. Acabou faltando tempo para escrever uma documentação decente :( A única que tenho é sobre como compilar o OSL, que foi feita antes de eu escrever o script de compilação.

Não só pela parte da documentação, mas no geral, fiquei com a sensação de que meu trabalho está incompleto. Gostaria de voltar a trabalhar nesse projeto assim que eu tiver mais tempo (leia-se defender minha tese). Espero que meus mentores considerem meu trabalho satisfatório e eu seja aprovado nessa segunda etapa do google summer of code.

Os comentários estão fechados.

%d bloggers like this: