| Age | Commit message (Collapse) | Author |
|---|
|
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
The following build:
$ make clean && make gb_CppunitTest_sc_ucalc
[...]
$ cd sc
$ make gb_CppunitTest_sc_ucalc
triggers:
sc/CppunitTest_sc_subsequent_filters_test.mk:133:
*** Missing font filelist -> run make more_fonts extras.
This didn't help the general Win32 font build problem AFAIK. There
were additional patches to the way Windows loads the LO provided
fonts, so just revert this.
This reverts commit 368c996b24e09c427a30972b3405493328db6779.
Change-Id: I841f96fe8312c47980c8e3be2e9d88242df5b28d
Reviewed-on: https://gerrit.libreoffice.org/84633
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The current dependency is already a hack, because there is no way
I know of to depend on delivered top-level modules like more_fonts.
The original patch parses the gb_Package_MODULE_ooo_fonts list of
registered packages to add them as build dependencies.
But this is not sufficient, as it just adds the dependencies on the
installed / unpacked fonts in the workdir (actually it's just the
installer filelist), where they can't be found by the unit test
running in the instdir environment.
So this converts the depndency into a make error, if either the
filelist is missing or the included font files. But if we are in
a full run and know the more_fonts module, we simply depend on its
delivered files.
This needs some minimal changes to gbuild, as neither the delivered
file list nor the modules class names are yet available. And this
moves the fontconfig handling to extras, where the opensymbol font
is already handled.
Change-Id: I1b70a4c45ff189266ce56c57e534ddc45e7c5c19
Reviewed-on: https://gerrit.libreoffice.org/74624
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
At least for me on Linux since LO 5.3, 'soffice
sw/qa/extras/rtfexport/data/fdo72031.rtf' shows "Å" (rendered in "DejaVu Sans")
instead of "⊕" (rendered in "Standard Symbols L"). That's presumably because
47ea13ef8dc8ab9aeded6121845e3ebd1d28b292 "Kill the old Unix layout engines"
removed support for Type 1 fonts (see "Ignore Type 1 fonts" in
FontCfgWrapper::addFontSet, vcl/unx/generic/fontmanager/fontconfig.cxx), and my
(Fedora 25) /usr/share/fonts/default/Type1/s050000l.pfb "Standard Symbols L" is
a Type 1 font. So we fell back to fontconfig's generic (weak) suggestion of
"DejaVu Sans" as a substitute for "Symbol".
So extend our fc_local.conf to suggest our "OpenSymbol" as a substitute for
"Symbol".
As that fc_local.conf was originally brought along by --with-fonts, which is
enabled by default but can be disabled, compilation of fc_local.conf from the
various snippets is moved to postprocess.
macOS and Windows were never affected, as they both come with a "Symbol" font
installed in the system. (And we don't install fc_local.conf on Windows at
all.)
Change-Id: I8d6d87f24974577fd66f5f3989f606237ebb3d75
Reviewed-on: https://gerrit.libreoffice.org/42670
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
