Development/Archive/Build in 3.6

The short version for the impatient
Env.host.sh and Env.Build.sh are no more.

To build the product use:

./autogen.sh make

To build/re-build a specific module use

make .clean # to clean the module make

for modules that are still under dmake you can also use make .deliver # 'deliver' the module make .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.


 * to build a given module
 * .clean to clean a given module
 * .all to do a build --all on dmake 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.