Development/Archive/Build in 3.6

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

This page was marked as inactive and is retained for historical reference.
Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as one of our mailing lists.

The short version for the impatient

Env.host.sh and Env.Build.sh are no more.

To build the product use:

./autogen.sh <options>
make

To build/re-build a specific module use

make <module>.clean # to clean the module
make <module>

for modules that are still under dmake you can also use

make <module>.deliver # 'deliver' the module
make <module>.all # build the module and all its pre-requisite modules

Introduction

The build system used to involve configure.in, triggerring the generation of a perl script set_soenv out of set_soenv.in, which in turn was invoked to generate Env.Host.sh/EnvBuild.sh, shells scripts that needed to be sourced to set-up the build environment.

This process was complicated, hard to follow (the set_soenv perl scrip was not trivial to parse), required to pollute one's shell to do partial build, and forced some contortion in gmake Makefile to be able to set-up the environment just-in-time.

Since we are pushing toward a gnumake build system, using an 'include' to set-up the build environment is desirable.

All the logic contained in set_soenv has been pushed in configure.in. autogen now generate the file config_host.mk out of config.host.mk.in. This file contain an alphabetical list of variables whose value has been determined in configure.in, in a form that is compatible with a gnu Makefile.

What's New

From a usage point of view. Now every build action should be doable from the source root directory. The usual build,check,dev-install,install... are still there.

A new set of target have been added.

<module> to build a given module
<module>.clean to clean a given module
<module>.all to do a build --all on dmake module
<module>.deliver to 'deliver' a given dmake module

Furthermore, since the build environment is not sourced in a shell anymore, and there is no direct way to source it, a new target 'cmd' has been added to cover corner cases... that target execute the command contained in the environment variable $cmd in a sub-shell with the build environment set. for example:

make cmd cmd="env | sort"
make cmd cmd="cd libwpd && deliver -delete"

This is really meant to be a 'corner' case escape trick. if you find yourself needing that trick too often, that probably indicate that a regular target need to be added to the main Makefile.

Cross-compiling

cross-compiling involve building some modules on the 'build' side and the rest of the product on the 'host' side of the cross-compilation. This is managed automatically on a full build. but if you need to build/rebuild specific module on the build side, you can do that by setting the variable gb_Side="build" like:

gb_Side="build" make idl

Things to be aware of

The old method used to explicitly unset any variable that was set to empty. the new system export them as empty. In most case the build system rely on the variable being empty, and not on it being undefined... Still there was a few places that relied on 'undefined'. It is possible that some were missed.

The root-source-directory Makefile contain a list of dmake and gmake modules. That list need to be updated if you convert a dmake module.