In the first blog post on LibreOffice build system, gbuild which uses GNU Make, I discussed some of the features of it. Here I discuss more about some gbuild tips and tricks that you may need.
Building a Single Module
In order to build a single module, you need to use its name. For example, to build only “odk”, which contains office development kit, you only have to type:
make odk
On the other hand, there are many other build targets associated with odk. By typing make odk, and then pressing tab, you will see this list, which shows possible targets:
odk odk.buildall odk.perfcheck odk.uicheck odk.all odk.check odk.screenshot odk.unitcheck odk.allbuild odk.checkall odk.showdeliverables odk.allcheck odk.clean odk.slowcheck odk.build odk.coverage odk.subsequentcheck
Each of the above is related to a specific task, in which many of them are common on different modules. Let’s discuss some of them:
make odk -> Builds odk module.
make odk.clean -> Cleans the odk module, removing the generated files.
make odk.check -> Runs test in odk module
make odk.uicheck -> It runs UI tests inside odk module
make odk.perfchek -> Runs performance/callgrind tests inside odk module
make odk.screenshot -> Creates screenshots inside odk module
To get a complete list and detailed description, run make help.
Handling Incomplete Builds
Sometimes because of OS crash or power outage, you may face problems when a build is stopped forcefully. In that case, you may see several zero byte object (*.o) files that exist, and prevent a successful build. In that case, you can find and remove them using this command:
$ rm `find -name *.o -size 0`
After that, you can retry your build without the above problem.
Customizing Build Configuration
The process of creating Makefile starts from configuring LibreOffice for build. This is done by invoking ./autogen.sh. The configuration parameters are read from autogen.input. The build configuration is done via configure.ac, which is an input for GNU autoconf.
There are various steps before the Makefiles are generated. For example, in order to make sure that a library is there when configuring the build, a very small C/C++ file is created, compiled and tested to ensure that the library is ready, and available to use with C/C++ code.
It is also possible to check for some specific version of library, and available functions. As an example, see this patch, which checks for specific version of ZXing library:
In the above example, multiple situations are handled:
1) When there is no ZXing library
2) When system ZXing library is used
And also, it is checked that specific version of ZXing is available:
1) When ZXing::ToSVG is not usable
2) When ZXing::ToSVG is usable
Then, the HAVE_ZXING_TOSVG symbolic constant is used in config_host/config_zxing.h.in, which can be used in C++ code.
Knowing More About gbuild
If you are interested in knowing more about gbuild, you can start from my first post on gbuild in this blog. I plan to write more about gbuild, and describe some of the frequently used macros.
Also, you can take a look at the article devoted to gbuild in the TDF Wiki:
