ExternalProject usually involve a configure and a make
step that produce a bunch of output usually irrelevant
including a large number of warning and other mess.
now that everything is pretty much in tail_build
these output get interleaved with useful output from
the build of the product and actually drown them in a logorrhea
of messy noise.
This store the output of external modules in a log file
and only print them as a whole if the module failed do build.
on a non-verbose build.
Change-Id: I3abfcccd6d16821a9e061a71e031b427cc283647
Reviewed-on: https://gerrit.libreoffice.org/2304
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
We don't use the debugging runtime in LO's own code in dbgutil builds,
so we shouldn't use it in bundled libs either.
(At one point I did try to use the debugging runtime in a dbgutil
build, but had to give up eventually; too many compilation errors
thanks to using -D_DEBUG which brings in much more strict checks in
the C++ headers. I apparently forgot to fix these makefiles then when
I aborted the attempt.)
Change-Id: I I Iedf765b55ba71b811d7fe3074e4c3129783108fd
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
...by allowing our special @___... tokens anywhere within an install name,
so that external modules can configure --prefix=/@___... etc. This removes
the need for the special extshl and EXTRPATH=LOADER. Also, a new
OUT2BIN_NONE can be used for external modules where the generated libraries
need the default EXTRPATH=OOO, but generated executables are only used
during the build and such need RPATH=NONE.
Passing the debug=yes option to libxml2's configure.js causes it to be
built against the debugging runtime, which is not what we want if we
just have used --enable-debug. It is with --enable-dbgutil that we
want to use the debugging runtime. So look at $(dbgutil), not
$(debug).
In the spirit of 12759f67a3, change
external lib's config.sub to eat the arm-unknown-linux-androideabi
host os string. Also, permit shared libs again - seems Android can
handle those.
Added dictionaries to cross-build-toolset - idxdict is needed.
Should build up to sfx2 - some residual static lib issues there,
and in raptor.
Building libxml2 with VC++ 2008 Express Edition on Windows platform where
the locale is Japanese (or maybe Korean, Chinese or others) fails because
some files generated by test tools in libxml2 contains non-ASCII characters.
This issue is originally reported in OpenOffice.org community (issue 93433)
and a patch is provided by tora, but it has not been applied yet. This
modification is based on the patch and adapted to the current LibreOffice
source.
