Categoría: OOo

Este fin de semana me he liado la manta a la cabeza y me he puesto a compilar OpenOffice.org. Tengo una idea que me gustaría programar algún día relacionada con OOo, y uno de los primeros pasos consiste en saber compilar la bestia 🙂   No ha sido tan duro como parecía a simple vista.

Por si alguien más está interesado, he apuntado los pasos que he ido dando. Parto de Ubuntu 8.10, totalmente actualizado.

Lo primero sería descargar desde Subversion la aplicación ooo-build, que no es más que un script de configuración y ayuda a la compilación de OOo:

svn co svn://svn.gnome.org/svn/ooo-build/trunk ooo-build

Lo siguiente será instalar las dependencias (las he ido sacando una a una, por prueba y error, así que esto os ahorrará mucho tiempo):

$ sudo apt-get install
libpam0g-dev
flex
bison
mono-2.0-devel
libcupsys2-dev
gperf
libxslt
libpq-dev  (pq_config)
libcurl4-openssl-dev  (curl-config)
unixodbc-dev  (odbc)
xulrunner-1.9-dev  (libxul-nss)
libsane-dev
libxaw7-dev
libgstreamer0.10-dev
libgstreamer-plugins-base0.10-dev
libxtst-dev

También es necesario instalar un módulo Perl disponible en CPAN, así:

$  sudo perl -MCPAN -e ‘install Archive::Zip’

A continuación, la orden ./configure típica, con dos detalles:

$ ./configure –with-distro=UbuntuIntrepid  –disable-kde

En mi caso uso UbuntuIntrepid. Y no quiero tener nada que ver con KDE O:-)  (lo siento Marcos)

Para ver la distro que más se ajusta a vuestro PC podéis consultar el siguiente directorio:

$ ls -al distro-configs/

Sien el proceso de configuración observais que alguno de los parches que se quieren aplicar propios de vuestra distro no funciona, podéis comentar la línea que haga referencia a ese parche. Por ejemplo, en mi caso, ví que el parche ubuntu-lpi.diff no se aplicaba correctamente, por lo que comenté la línea que hacía referencia al mismo en el fichero  ooobuild/patches/dev300/apply

A continuación, descargar todos los paquetes de código fuente necesarios con una sencilla orden:

$ ./download

Y proceder a compilar

$ make

Aviso a navegantes: la compilación de OOo en mi ordenador (Dell Inspiron 530, comprado recientemente) duró unas 4 horas. Con ordenadores un poco más antiguos el proceso puede durar hasta 7 horas. Así que prepara un buen café y tómatelo con calma.

Cuando termines, instala tu OOo recién salido del horno (nunca mejor dicho) así:

$  ./bin/oooinstall /opt/ooo310-m6

La creación de una nueva funcionalidad en cualquier proyecto software no trivial requiere seguir una serie de pautas y métodos que aseguren que lo que se va a crear se hace según lo especificado, en el tiempo acordado y con el coste previsto. Para conseguirlo, es necesario pasar por una serie de trámites que harán además que lo creado pueda ser revisado, modificado o reutilizado en el futuro sin dejarse la salud en el intento. Crear una nueva funcionalidad en OpenOffice.org, aunque sea pequeña, requiere también pasar por un proceso de documentación ingenieril que aunque pueda asustar al principio, se ve como algo imprescindible si se quiere que OOo sea una suite ofimática de calidad. Un ejemplo de todas estas abstracciones lo podemos encontrar en la nueva funcionalidad «overline» prevista para OpenOffice 3.1.

Para que esa nueva funcionalidad se aceptara en OOo Writer, lo primero que tuvo que hacer su autor es redactar una completa especificación siguiendo la plantilla que el equipo de revisión de OOo (iTeam) ha preparado al efecto. Alguien podría decir, bueno, no hace falta todo esto para poner un efecto de subrayado superior a las fuentes… hasta que se da cuenta de que ese efecto requiere un cambio/añadido en la especificación del estándar OpenDocument… vaya, pues sí, habrá que hacerlo. Luego se da cuenta de que ese cambio incluye nuevas cadenas de texto en el interfaz, que por supuesto habrá que traducir. «Ah… pues también es verdad». Cuando ha terminado, observa que el API UNO de OOo también debería de ofrecer la posibilidad de cambiar por programación el efecto de subrayado superior… etc., etc. El redactar una especificación requiere pensar y hacer frente a todos esos problemas (y más) por escrito. ¿Hemos terminado? No. El equipo iTeam de OpenOffice requiere también, para el control de calidad, la redacción de una serie de «pruebas unitarias» para el interfaz gráfico. Una serie de pasos muy detallados con un final esperado. Algo del estilo: «Pulsa en Nuevo documento writer, elige Formato/Carácter en el menú. Pulsa la pestaña Efectos de Fuente. Selecciona «Overline» en la lista, la primera opción debería de ser «Sin subrayado», comprueba que en el desplegable Color, la opción por defecto es «Sin color»…» Son especificaciones de casos de prueba (Testcase specifications)

Si queréis saber más al respecto, podéis echarle un vistazo a esta presentación bajo el título «The OpenOffice.org specification process demystified»