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 now have a single libexpat instead of libascii_expat_xmlparse and
libexpat_xmltok. Hmm, no idea when that changed, but OK, that just simplifies
the fontconfig patch. (Note that the bundled fontconfig is used only for
Android.)
Change-Id: I3973d35a566bd3c86b013c96b7f3a6a8e249c2c0
This reverts commit 78c7bbc3ce.
It is no longer the case that both expat_utf8 and expat_utf16 are linked
into the same library: we only use expat_utf16 in shell Explorer
extensions, which cannot be linked into libmerged anyway.
Conflicts:
expat/expat-2.1.0.patch
Change-Id: I579c10d405d8a40cafcb2dbe09e967c6079f7b16
So we need to use the expat subdir too in
--with-expat-includes. Apparently until now it did not find expat.h,
so it fell back to libxml2 instead then, which was sometimes found OK,
sometimes (on tinderboxes) not. (It even went looking in the *build*
platform /usr/include, eek!)
Change-Id: If0595b810d531b5aa7110f375d4d0dfb0b01617b
Rationale:
- it is advised to use max-jobs and num-cpus with the same value in wiki
- max-jobs was used only for lcms2 and few gbuild
modules outside of tail_build anyway.
Also fixes:
- really use CHECK_PARALLELISM when meant to
- EXTMAXPROCESS is not defined in gbuild;
use parent's jobservers in sub-make where possible
Change-Id: I501de732d223ce0c935081bd1d73da611d16ee88
Reviewed-on: https://gerrit.libreoffice.org/930
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
For some reason $(LIBS) seems to contain a bunch of unneeded libraries
including -llo-bootstrap when we get here. Those won't be found by the
basic configury as there are no -L switches included, causing the
lovely "C compiler cannot create executables" problem.
Change-Id: Id7cfba191bd16649c7948194eb7ebdbfbfb74f3e
Said executables will not be used for anything, of course.
We can't use gb_STDLIBS, which also contains -lm after my previous
commit, as fontconfig is C, not C++, and gb_STDLIBS contains
-lgnustl_static, and only our $(CXX), not $(CC), contains the -L that
points to where -lgnustl_static is to be found.
Change-Id: I40c459580f357d913ddc55eae00e16f90f81d510
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
Sigh, spent one day, more or less, tracking down a weird fontconfig
problem, where all the diagnostic it offered was "unknown encoding"
when reading the fonts.conf file.
It turned out that I was being screwed by our fun two versions of the
expat_xmlparse library: One where XML_Char is char and one where it is
short. The intuitively "more normally" named libexpat_xmlparse is the
latter, but fontconfig works only with the former as it implicitly
expects XML_Char to be char.
It will probably be simplest to just use FreeType on Android,
too. (Android uses it itself, but doesn't provide its API publicly.)
Probably fontconfig, too, although there shouldn't be much
configuration per se that a LibreOffice-baed app would have to do at
run-time; it will have to bundle all fonts it is going to use anyway,
I think, so all font information is known a priori. But maybe in the
future there will be user-installable system fonts on Android, or
something.
