Development/Archive/Build in 3.6

    From The Document Foundation Wiki
    Gnome-document-open-recent.svg

    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.