Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gcaiod-ooo-dev@m.gmane.org
 designates 80.91.229.3 as permitted sender)
To: ooo-dev@incubator.apache.org
From: Armin Le Grand <Armin.Le.Grand@me.com>
Subject: Re: Removing output trees during the bootstrap step?
Date: Thu, 23 Feb 2012 15:34:22 +0100
Lines: 61
Message-ID: <ji5ipe$h7h$1@dough.gmane.org>
References: <4F4643EF.6050503@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
In-Reply-To: <4F4643EF.6050503@apache.org>

	Hi Herbert,

On 23.02.2012 14:49, Herbert Duerr wrote:
> For a long time the old build system had the problem that build
> dependencies between modules had to be set manually and this was quite
> fragile, of course. It can result in obvious trouble like compile or
> link failures and what is more troubling are subtle problems, like
> struct changes going unnoticed by a source file depending on it. The
> result are hard to debug and "interesting" artifacts.

The dependencies for files are now global (see e.g. 
trunk\main\solver\340\wntmsci12\workdir\Dep\CxxObject\svx\source\svdraw\svdobj.d 
in a built win environment), it's not like in the old in-house build 
system. This is because MKDEPENDSOLVER=TRUE is the default now (I ofteh 
set that var since I needed glopal deps for incompatible builds from svx 
which happened often to me).

Thus, for building incompatible you do not need to remove the output 
trees, I use it and it works pretty well.

For changed configure options it may be pretty different, thus when 
changing the configuration for an already built trunk you still have to 
know what you are doing.

Still, I would not make it a default to remove all output trees on 
default when using bootstrap.

> The gbuild process has many benefits one of which is its automatic
> handling of dependencies. Volunteers are very welcome to migrate the
> remaining modules. In the meantime we have to deal with the dual
> gbuild/oldbuild process which complicates the dependency problem more.
> The manually set dependencies of the old build system where also not
> perfectly debugged which showed when the build order was changed, e.g.
> by doing a highly parallel builds on beefy buildbots. Fixing all to the
> the old-build dependencies would help too, volunteers are very welcome.
>
> Looking for a solution that works reliably for the very near future I'm
> considering to add a "clean output trees" to the bootstrap step. It
> would make sure that all is rebuilt when the configuration gets changed.
> Of course you could prevent that (by setting an environment variable
> DO_KEEP_OUTPUT_TREES) but the default should be to go the "better safe
> than sorry" way.
>
> --- a/main/bootstrap.1
> +++ b/main/bootstrap.1
> @@ -22,3 +22,11 @@ if [ "$DO_FETCH_TARBALLS" = "yes" ]; then
> $SRC_ROOT/fetch_tarballs.sh $SRC_ROOT/ooo.lst
> fi
>
> +# remove all output trees
> +# TODO: this is no longer needed when all dependencies are perfect
> +# or when the switch to the gbuild system is complete
> +if [[ -n "$DO_KEEP_OUTPUT_TREES" && -n $INPATH && -n $OUTDIR ]]; then
> + echo Removing the output trees
> + rm -rf "*/${INPATH}" "${OUTDIR}"
> +fi
> +
>
> Herbert
>