Hoje à noite, em um momento iluminado (depois de ler um e-mail do Juca entitulado “algumas coisas demandam coragem”, sugerindo o que se segue), pensei: bom, se eu já uso as versões de desenvolvimento do Firefox e do Thunderbird cotidianamente, por que não o OpenOffice? Afinal, qual a graça de usar um OpenOffice 3.1 estável?!

Há cerca de dois anos eu tentei completar esse rito de passagem: na época ainda usavam CVS. Um grande problema de CVS em tutoriais é que sempre colocam umas linhas de comando do tipo:

cvs -d :pserver:anoncvs@anoncvs.services.openoffice.org:/cvs checkout "modulename"

e nunca nos dizem o que colocar em “modulename”, o que acaba por custar ao benevolente hacker mais duas horas varrendo o repositório em busca do módulo correto. Além disso, era necessário baixar e compilar separadamente todo o build system do open office.

A boa notícia é que a cada major version o OpenOffice.org tem refeito o seu build system, para melhor. Além disso, descobri que nesses dois anos eles passaram o repositório de código pelo svn e finalmente adotaram o mercurial em outubro de 2009.

Fazer um checkout de todo o repositório mercurial seria muito demorado, e por isso eles disponibilizam um bundle diário do repositório, isto é, um arquivo com todo o repositório empacotado.

Hora de se sujar: baixe o bundle , “unbundle” e “update”:

sudo apt-get install mercurial (caso não tenha o mercurial instalado)
mkdir devel && cd devel (ou como vc quiser chamar o seu parque de diversões hacker, caso ainda não o tenha)
wget http://hg.services.openoffice.org/bundle/DEV300.hg
mkdir openoffice
cd openoffice
hg init
hg unbundle ../DEV300.hg
hg pull http://hg.services.openoffice.org/DEV300
hg update

Além do tempo de baixar o bundle, que tem quase 1GB, o resto do processo demora cerca de 30 minutos.

De agora em diante, você é livre para compilar como quiser, com os itens opcionais que quiser (ou não). Vou apenas reproduzir o que eu fiz para executar um full build padrão, já que os tutoriais oficiais nunca são suficientes. Tudo isso foi executado em um Ubuntu GNU/Linux 9.04 (jaunty) 64bits, e pode mudar ligeiramente de distribuição para distribuição. Caso você use uma distribuição que não seja derivada do Debian (isto é, sem apt), use o gerenciador de pacotes padrão da sua distribuição. Os pacotes devem ter nomes iguais ou parecidos.

Dependências

No tutorial disponível no wiki eles sugerem algumas dependências:

• glibc:
  for OOo<=3.1: 2.2.x or higher for OOo>3.1: 2.3.2 or higher
• C/C++ Compiler:
  gcc >= 3.3
  gcc 4.2.3 is the current reference compiler
• The X11 development libraries and header files
• PAM including the development headers
• bash
• gtk2 and libtiff including the development headers

Se você não estiver usando um Debian Sarge da vida, ignore e prossiga. Ah, caso você não tenha o gcc instalado, 1. você não devia estar aqui (bazzinga!) 2. já que está aqui, rode um sudo apt-get install build-essential e seus problemas acabaram.

Isso é uma mão na roda para instalar a maioria das (infinitas) dependências:

sudo apt-get build-dep openoffice.org

Como de praxe, há coisas novas em relação à versão estável que obviamente o build-dep não pegou:

sudo apt-get install mingw32 libgraphite3 libgraphite-dev

De volta ao seu diretório openoffice:

./configure --with-use-shell=bash --with-system-libs --without-system-jars --without-system-icu --without-system-agg --without-system-lpsolve --without-system-mspack --disable-mozilla --with-mingwin=/usr/bin/i586-mingw32msvc-g++

Isso diz aos scripts de compilação para utilizarem o maior número possível de libs do sistema e evitar incompatibilidades. O palavrão /usr/bin/i586-mingw32msvc-g++ é para o cross-compilador mingw32, necessário para cross-compilar algo que não sei o que é. Ao final, veja se não ocorreram muitos warnings e se aparece a seguinte mensagem:

Configure completed
You may now run ./bootstrap in [pasta onde estão os sources]

Agora, com as variáveis de sistema configuradas, precisamos gerar os scripts de compilação (Makefiles):

./bootstrap
source LinuxX86-64Env.Set.sh
(ou source LinuxX86Env.Set.sh se seu processador for 32 bits)

Agora, aos finalmentes

Tendo configurado as variáveis de ambiente e gerado os build scripts, vamos à compilação:
time make

# vá tomar um chá que vai demorar (eu fui!). O time antes do make vai marcar o tempo gasto na compilação.

Depois do chá

Se tudo correr bem, depois do seu chá e mais algumas horas você chegará em algo assim:

***********************************************************
Successful packaging process!
***********************************************************
... creating log file log_DEV300_en-US.log
Fri Feb 5 12:30:15 2010 (00:07 min.)
real 357m1.283s
user 274m55.902s
sys 42m31.595s
rodrigo@snowball2:~/devel/openoffice$

Sim, foram 6 horas mesmo. Isso num Intel Core2 Duo T7250 2.00GHz com 4M de cache, mas utilizando apenas um núcleo. Coloque aí nos comentários os seus resultados para compararmos.

Caso você tenha um processador com dois ou mais núcleos, é possível fazer um build paralelo, que teoricamente iria mais rápido. Eu estava fazendo outras coisas no computador, então me contentei com um único core compilando o bichinho. No link ao final da página há instruções sobre como fazer isso, entre outros hacks.

Como executamos um full build, o processo gerou pacotes prontos para instalação. Os pacotes para GNU/Linux 64bit ficam em ~/devel/openoffice/instsetoo_native/unxlngx6.pro/OpenOffice/deb/install/ (para 32bits é unxlngi6.pro ou algo que o valha). Na pasta en-US_download há um tar.gz que pode ser distribuído. A pasta en-US possui o mesmo conteúdo, porém não compactado.

Instalação

Como executamos um build padrão, o configure gerou os pacotes nativos da distribuição: .deb. Caso você queira instalar o OO que compilou (óbvio que quer!) será necessário remover o OpenOffice que vem com a distribuição (se souber como gerar o build desempacotado e evitar isso, por favor faça um comentário).

sudo apt-get remove openoffice.org-common
(Caso você não remova o open office atual, pode haver conflito de pacotes. Remova!)

cd ~/devel/openoffice/instsetoo_native/unxlngx6.pro/OpenOffice/deb/install/en-US/DEBS
sudo dpkg -i *.deb (pacotes do OO.org)
cd destop-integration
sudo dpkg -i *.deb (ícones no menu do KDE/GNOME)

Lembre-se de autalizar o código (hg pull && hg update) e recompilar (make) de tempos em tempos. A linha de desenvolvimento está em constante… desenvolvimento (!), e se sua intenção vai além de fazer uma graça é importante estar com o código em dia. Vale lembrar que, a princípio, os rebuilds devem demorar muito menos, pois apenas os arquivos modificados (e os dependentes deles) são recompilados. Veja o link abaixo para maiores informações.

Agora, se suas intenções são realmente corajosas e vão além de testar e reportar bugs, entre na lista de e-mails dev@openoffice.org, dê uma olhada no bugtracker e na página de TODO’s. O wiki também é um ótimo ponto de partida.

happy hacking!

Referência:
http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Linux

© 2010 Rodrigo Rodrigues da Silva. Este texto pode ser compartilhado sob os termos da licença Creative Commons By-Sa

O primeiro passo, é editar o código. Para isso, você pode transferir os “.c” via FTP, alterar em outro SO ou, a maneira mais simples, que explicarei aqui, editar no próprio Minix.

No exemplo, vamos alterar a mensagem de boas vindas do Minix.

cd /usr/src/kernel
cp main.c main.c.back
elle main.c

Isso criará um backup do main.c, caso você faça alguma besteira e abrirá o programa Elle (um editor básico, mas que dá pro gasto) com o main.c.

Agora vá na parte que tem a mensagem de boas vindas (Copyright…..) e altere o código. Eu alterei para “By Russo – Sao Paulo – Brasil – 2009″.

Aperte CONTROL+W para salvar o arquivo e depois CONTROL+S para sair do Elle.

Agora digite

cd /usr/src
make clean
make install

edit: ou digite:

cd /usr/src/tools/
make hdboot

Depois que terminar a recompilação, basta reiniciar o Minix com

reboot

Pode acontecer disso simplesmente não funcionar, aí entra a segunda parte desse tutorial.

Alternando entre as recompilações

Depois de MUITO apanhar com recompilações e mais recompilações do Minix, com resultados alternados de funcionamento, testes e mais testes com VirtualBox, VMware Fusion (que insiste em dar um kernel panic no Mac OSX cada vez que dou um boot no Minix), Parallels Desktop e Q (versão do QEMU pro OSX), consegui entender o que acontece e como fazer uma compilação do kernel funcionar corretamente!

VMware tirando um sarro da minha cara

Acabei decidindo por utilizar o VirtualBox 3.0. Pesquisei que nem um condenado pelo mundo virtual e descobri que cada vez que o código é recompilado é gerado uma nova versão do kernel. O grande mistério que fica sem resposta é: por que às vezes ele reinicia com o kernel recém compilado e às vezes não?

Enfim, digite

ls /boot/image

Isso mostrará todas aquelas 300 vezes que você compilou o kernel para tentar alterar a “disgrama” da tela de login!

Versões das recompilações

Pode-se observar que recompilei o kernel três vezes (com a mesma alteração estúpida de teste), já que a primeira versão é a original.

Para utilizar uma dessas versões (no exemplo, vou usar a 3.1.3ar4), você deve digitar

#shutdown
image=/boot/image/3.1.3ar4
boot

Isso irá reiniciar o Minix com as alterações feitas em cada uma das versões. Além de resolver o problema de recompilações que aparentemente não funcionam, permite que você volte a versões pré-cagada!

Antes e depois de trocar o kernel em uso

No caso de dar caca, basta, na hora que o Minix te dá 3 opções (antes do boot) pressionar esc. Dessa forma, você tem a opção de escolher qual versão bootar.

Mas… se der caca numa alteração de driver… se danou! Faça backups com a maquina virtual para esses casos, já que mudanças nos drivers não tem nada a ver com o kernel do Minix e não adianta voltar atrás.