Construindo o LibreOffice no Linux: Dicas e truques

From The Document Foundation Wiki
Jump to: navigation, search

Em geral, a forma mais fácil de construir o LibreOffice é no Linux, porque com os seguintes comandos:

sudo apt-get build-dep libreoffice # somente para Debian/Ubuntu sudo zypper si -d libreoffice # somente para OpenSUSE 11.4+ sudo yum-builddep libreoffice # somente para Fedora 15+ & derivados (era openoffice.org) git clone git://anongit.freedesktop.org/libreoffice/core libreoffice cd libreoffice ./autogen.sh make dev-install

será criada uma boa instalação local, que você poderá executá-la com:

make debugrun

já diretamente sob um depurador. Você pode então abrir o Writer com o comando:

(gdb) run -writer


Só leia a partir deste ponto se você procura maneiras de otimizar sua compilação ou de resolver problemas dela.
Note que as dicas abaixo são uma coletânea misturada de observações que podem ou não se aplicar ao seu caso.




Esta página documenta como compilar a versão atual em desenvolvimento do LibreOffice, baseada em um repositório git chamado "core". Como construir versões anteriores, como os lançamentos 3.3, 3.4, está documentado aqui (em inglês).

Tutorial em vídeo

Saiba que existe um tutorial em vídeo (em inglês) sobre como começar sua primeira compilação. Embora ele seja feito em um sistema Ubuntu, deve funcionar com poucas modificações em qualquer sistema Linux (veja abaixo mais detalhes se precisar). Recomendamos assistir ao vídeo enquanto realiza os passos: ele não só lhe orienta durante a configuração, tem também uma excelente trilha sonora! ;)

Preparação

Dependências

O primeiro passo é ter certeza de que tem todas as dependências necessárias na sua plataforma para construir o produto. Existe uma página extra que detalha como instalar as dependências de compilação no Linux (em inglês).

Espaço em disco

No mínimo, com todos os repositórios git e o produto compilado e empacotado, você precisará de uns 7 a 10GB de espaço em disco, dependendo da plataforma, das opções de construção e das opções do autogen específicas usadas; e de alguns gigabytes a mais se você fez uma compilação para depuração.

Bear in mind that if you want to do more than just building the product once for your own enjoyment, you most likely will want to have more than one working directory (we will see later how to set them up). A workdir allow you to have a separate build environment without having to duplicate the git history, but it will still cost you 6 to 9 Gb per workdir.

Obtendo o código

No resto deste tutorial, trabalharemos no diretório ~/git. Claro que você é livre para escolher o diretório que quiser como ponto de partida.

Agora vamos baixar o repositório git chamado "core":

$ mkdir ~/git
$ cd git
$ git clone git://gerrit.libreoffice.org/core libo
Cloning into libo...
Remote: Counting objects: 76845, done.
remote: Compressing objects: 100% (17328/17328), done.
remote: Total 76845 (delta 60786), reused 74045 (delta 58579)
Receiving objects: 100% (76845/76845), 15.82 MiB | 1.17 MiB/s, done.
Resolving deltas: 100% (60786/60786), done.
$ cd libo

O código do LibreOffice ficará então em ~/git/libo

Inspecionando um ramo de lançamento

Ramo de lançamento antes da 4.0

Por padrão, o git lhe dará o ramo "master" em uma nova clonagem. Se quiser alter sua cópia de trabalho para um ramo de lançamento, primeiro faça isto ante de executar "autogen.sh":

$ git checkout -b libreoffice-3-5 origin/libreoffice-3-5

Após ter clonado os outros repositórios (veja "make fetch" abaixo), faça isto para também trocá-los para o ramo de lançamento:

$ ./g -f checkout -b libreoffice-3-5 origin/libreoffice-3-5

Ramo de lançamento a partir da 4.0

Execute autogen.sh no master, e então execute

make fetch

para buscar os submódulos que possam ser necessários dependendo dos parâmetros passados para o autogen.sh .

Então, troque de ramo com

$ ./g checkout -b libreoffice-4-0 origin/libreoffice-4-0

Em geral, evite trocar de um ponto antes da 4.0 para um ponto na ou depois da 4.0, ou vice-versa, já que mudamos a maneira como lidamos com os repositórios git auxiliares entre as versões 3.6 e 4.0...

Autogen

Agora você precisa configurar sua compilação. isso é feito executando um script chamado "autogen.sh". Existem muitas opções que podem ser passadas para esses scripts. Por isso, consulte esta página descrevendo as opções para detalhes.

Depois de executar o autogen.sh pela primeira vez, você pode também obter uma lista das opções (em inglês) executando:

$ ./autogen.sh
[uma longa saída]
$ ./autogen.sh --help
'configure' configures LibreOffice 4.0 to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:
  -h, --help              display this help and exit
      --help=short        display options specific to this package
      --help=recursive    display the short help of all the included packages
[....]

Suas opções podem variar, dependendo da sua plataforma e distribuição. Aqui estão alguns exemplos:

$ ./autogen.sh --enable-dbgutil --without-junit # usado no linux
$ ./autogen.sh --enable-dbgutil # usado no MacOS
$ ./autogen.sh --enable-dbgutil --without-help --without-myspell-dicts # sem repositórios externos (só o core)

A opção --enable-dbgutil configura para uma compilação para desenvolvimento, desabilitando otimizações, habilitando o suporte a depuração e conferências adicionais.

Dicas para compilação no Linux

Veja dicas independentes da platforma em Development/GenericBuildingHints/pt-br em inglês.

Start what you have built

To run the LibreOffice you have just built, do

$ make dev-install -o build

and the output will show how to start the program. Typically this is ./install/program/soffice, which comes from the Makefile. Note that without the -o build option, it will do the complete build before performing installation. If you have just completed the full build, then pass the -o build option to skip doing another build.

Performance

Building LibreOffice takes time, a lot of time. Exactly how much depends on how powerful your machine is. But there are tools you can use to speed-up things.

ccache

ccache is a tool that caches the results of c/c++ compilation to try to re-use them later. It will not speed-up your initial build (on the contrary it will slow it down a bit), but it can dramatically speed up later re-building. If you plan to do some hacking in LibreOffice, you will do that a lot, so it is a worthy tool to have.

By default, ccache will be enabled automatically if it is found on your system. For best results, you may want to increase the cache size or enable cache compression; `man ccache` is your friend.

Note that the default cache size is just 1G which is far too small to be useful for a LibreOffice build; for a build without debug symbols, you should have at least 8G cache, and for a build with debug symbols for everything probably 32G is a useful starting point. You can set the size like this (note that this setting is stored inside the cache directory, if you change the location by setting $CCACHE_DIR you have to re-do it):

ccache --max-size 32G

ccache also supports compression, which is very likely a good idea to enable (does anybody have hard numbers?), especially if you are using a small or slow storage medium, like a SSD or laptop hard disk. You can enable compression by adding this to your .bashrc or equivalent:

export CCACHE_COMPRESS=1

distcc / Icecream

If you are in an environment where you have access to multiple machines with spare cpu cycles, you can take a look at distcc or icecream, tools for distributed build.

Support for Icecream is built into LibreOffice, it is enough to add --enable-icecream to ./autogen.sh, and the configure process will pre-set number of jobs to use, and will try to find the icecream gcc wrappers in /opt/icecream/bin. Should you have them somewhere else, please use --with-gcc-home=/path/to/your/icecream/bin switch to override that.

--with-parallelism

The build process can be told to run multiple tasks in parallel. The parallelism is controlled by the autogen parameter --with-parallelism. If you have enough memory, I found that using --with-parallelism=n where n is your number of cores, or 2 for --with-parallelism if you have only 1 core, give me the fastest build time.

--with-parallelism already defaults to the the number of cores/cpus on your system, unless you use --enable-icecream - then to 10.

--with-system-libs

Building with existing libraries may speed up your build, but you have to fiddle with the dependencies.

Compiler flags

Certain compiler flags, most notably optimizations and debug information, enable additional compiler features, which make the build take longer time. If you do not need these features and want the build as fast as possible, you can explicitly disable them by setting CFLAGS/CXXFLAGS for gcc when running make:

$ CFLAGS='-O0 -g0' CXXFLAGS='-O0 -g0' make

Note that for development you generally want the build configured with at least --enable-symbols, which turns on debug information, so this is not generally applicable.

Approximate times

An Athlon 435 X3 with ccache without java without epm takes about 1.5 hours for the initial make on gentoo.

The first build, on an Intel 2630QM with ccache without java and epm with --with-parallelism at 8 and ext4 formatted disk takes about 1,5 h too on Kubuntu. The following daily build time varies between 2 and 10 min (depending on the number of modified or added files and their complexity).

Multiple Work Dirs

If you want to work on both the master branch, and the current release branch at the same time, you can share git repos, and external source tarballs (note the savings can be significant, especially if you also use the quite huge l10n repo). Note that switching branches within the same working dir is not recommended - the build dependencies for LibreOffice are still somewhat incomplete and fragile, and you'd likely have to perform clean re-compilations everytime you switch branches. If you can afford the diskspace, maintaining separate trees is the recommended way.

Setup

Prepare the first build on your disk just like explained above. For the second, and all other builds, do this to clone the initial core repo:

$ /other/libo/bin/git-new-workdir /other/libo /dir/to/be/created my-libo-branch

You'll notice a much quicker clone operation. After that, setup the new work dir with these two extra configure (or autogen.sh) options:

$ ./autogen.sh ... --with-referenced-git=/other/libo/clone --with-external-tar=/other/libo/src
$ ./g checkout my-libo-branch

Again, cloning will be much faster. You have to use an absolute path for the --with-external-tar option. After that, you proceed with building just like for the single-workdir case.

rpm not found/ant not found/no package gnome-vfs-2.0

--disable-epm This will fix "rpm not found", as autogen expects to find either dpkg or rpm on the system.

--without-java This will fix "ant not found"

As of the master towards LibreOffice 3.6, to build the UNO SDK you need to have Doxygen installed so that HTML documentation for the C++ UNO interface can be generated. One option is to install Doxygen from its website and make sure the doxygen executable is found on the PATH, or specify its exact location via --with-doxygen=pathname configure switch. Another option is to configure --without-doxygen, in which case the HTML documentation for the C++ UNO interface will be missing from the UNO SDK being built. A third option is to configure --disable-odk, in which case the UNO SDK is not build at all.

Note: Installing 'libgnomevfs2-dev' package on Ubuntu manually will fix "No package 'gnome-vfs-2.0' found" on older release branches. It should not be needed anymore on master by now. Use synaptic package manager or run in terminal

$ sudo apt-get install libgnomevfs2-dev

Unable to find source package for "libreoffice" on Debian/Ubuntu

# aptitude build-dep libreoffice
Unable to find the source package for "libreoffice".
Unable to find the source package for "libreoffice".
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.

You likely miss a source line in your /etc/apt/sources.list like this one (for Ubuntu) -- mostly probably such a line is already there and just waits to be uncommented:

deb-src http://archive.ubuntu.com/ubuntu/ raring main restricted

add it and do a apt-get update then the build-dep should work. (Unless you are on a ancient pre-libreoffice version: then you should try openoffice.org instead of libreoffice)