Adds three Windows gb_* variables:
- gb_MSBUILD_CONFIG_AND_PLATFORM can be passed as msbuild flags
- gb_MSBUILD_PLATFORM maps debug / release settings
- gb_MSBUILD_CONFIG maps the CPUTYPE to the default msbuild names
and converts the users in external projects.
Change-Id: Ie9b817721180d78d104db11c44241e4b3e46bba9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102701
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The revert commits change the build-tools target for a DESKTOP
build to build the complete LO. This restores the original,
minimal one and also adds a whitelist of allowd build types.
OpenCL needs a configure switch, as it's status is also stored
in a config header, so preventing the build is not enough.
This also reverts:
- commit 802161a505
- commit 02d931a59e
Change-Id: Ibfcb0c54e72da1b7c2e63c082ea6586520a787fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102480
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This changes the Windows build to use the default configure switch
to select the target / host of the compiled binaries to get the
possibility to cross compile on Windows the "default" way.
Note that selecting i686-pc-cygwin on x86_64 doesn't do a cross-
compilation, as no special build tools are needed, because x86_64
can run x86 binaries just fine.
A consequence of the change is the default target host, which is
now the same then the build system, instead of the previous x86
default.
Change-Id: I5584f34f665573ebac40d5d7753d96addeb84dbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102479
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The problem was that (cd sw && make CppunitTest_sw_ooxmlexport4) fails
with an error that the gpgmepp package doesn't exist, but only on WNT.
Nonobviously, this is due to the override of the rule for the gpgmepp
package in ExternalPackage_gpgmepp.mk, which copies the same file that
the package already depends on for no obvious reason.
Furthermore, RepositoryExternal.mk uses
gb_Helper_register_executables_for_install with gpgme-w32spawn,
when it should just register the package instead, because that is not a
gbuild Executable.
Change-Id: I8cb8b7a68c9681844a39de1390aa736a1ec53449
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100159
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
With all the prerequisites in place, LO can be updated to the
current Python release. Interestingly I found that Cygwin always
seems to use LC_COLLATE=C, probably because the default collation
rules are missing.
Then there are the changes introduced in "PEP 587 -- Python
Initialization Configuration", which appearingly have modified the
DLL search path behaviour on Windows, so the OpenSLL DLLs aren't
found anymore in the program directory. As a workaround, the
OpenSLL and libffi DLLs are now (also) installed into the Python
lib dir on Windows.
Change-Id: Ib82f7b77213da9c525f8c79a13d128d9eec9ca64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98437
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The OpenSSL 1.1.1 release is currently the only supported version
and it already has the Windows Arm64 support I was looking for.
This change also explicitly enables thread support, which Python
depends on since release 3.7, which removed the --without-threads
build option. But the explicit OPENSSL_THREADS was just added in
3.8.4, so the old no-threads build fails now and was wrong since
probably much longer.
Change-Id: I61d94f966bc59407f213f4a81f0a49d0c05f8948
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98435
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Using #define's directly from VCL will report the compiler used
to compile VCL, which may be different from the one used for Skia.
Also truncate the log file on opening.
Change-Id: Iddf613613df20505f1abe1dd5468dcc8c7041410
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97090
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
It was fairly pointless to be able to --disable-libnumbertext.
Besides, disabling it broke the ordinal page (etc) numbering feature:
"1st", "2nd", "3rd", etc showed up as "Ordinal-number 1",
"Ordinal-number 2", "Ordinal-number 3" etc.
Change-Id: I645169054a8fdc8dac89cd48b6c369fd61749467
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96119
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Bundled box2d with the build system of LO as a static library.
If --with-system-box2d was specified checks for instance box2d in
the system, defines SYSTEM_BOX2D and uses the library from the system.
Change-Id: Ifb05912f2acaff273b25abebafc5af1cac3afec4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94103
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Building e.g. Gallery_backgrounds from scratch failed there with
no suitable windowing system found, exiting.
Change-Id: Icf2dd26441554e573914f371d0d5eb21e99f5f0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93429
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In RepositoryExternal.mk, a system python automatically gets $PYPATH
added to $PYTHONPATH, but the internal one does not - this doesn't make
sense.
Try to remove it for system-case by fixing the one case that relies on
it and for which it was introduced in commit
84ef6d8254 to directly extend $PYTHONPATH
instead, which ought to work as long as it's not evaluated at global
scope and thereby avoids affecting all python invocations.
Change-Id: I4534f2be92b850dc01193cb1bb2e0a299a5152be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91748
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
The Cairo-based way reuses code that is used for OpenGL, but it's
needlessly complicated, given that Skia itself is capable of text
rendering as well.
This requires a small patch for Skia so that it uses the FcPattern*
we use for selecting a font.
The rendering with this commit is usable, but visually the result
is noticeably different, so this will need tweaks to the font
rendering (TBD).
Change-Id: I058c282307106c929ccc9faa7b2bddfabf0f0a2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90580
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
... representation of given decimal.
Use dtoa.c from https://www.netlib.org/fp/dtoa.c to build a custom
static library that doesn't use current locale (unlike strtod from
stdlib.h). This is the implementation used by e.g. python and nss
(search for "dtoa.c" under UnpackedTarball).
To avoid name clash with the standard strtod, rename the function
to strtod_nolocale.
Size of buffer on stack in ImpSvNumberInputScan::StringToDouble is
256 characters. Logging function usage in make check, of ~124 600
invocations, the longest string was 14 characters, average being
2.1 characters. So heap allocation is unlikely in scenarios with
intensive function usage.
After std::from_chars is available in baseline compilers, external
library can be dropped, and call to strtod_nolocale replaced with
the standard function.
The artifact at https://dev-www.libreoffice.org/src/dtoa-20180411.tgz
is created with
mkdir dtoa && mkdir dtoa/src && wget https://www.netlib.org/fp/dtoa.c -O dtoa/src/dtoa.c && \
printf 'd8bab255476f39ea495c8c8ed164f9077da926e6ca7afb9ad3c56d337c4484fe dtoa/src/dtoa.c' | sha256sum -c && \
tar -c --owner=0 --group=0 --mode=go=r,u=rw --mtime='Wed, 11 Apr 2018 15:59:39 GMT' dtoa/src/dtoa.c | gzip -n > dtoa-20180411.tgz && \
printf '0082d0684f7db6f62361b76c4b7faba19e0c7ce5cb8e36c4b65fea8281e711b4 dtoa-20180411.tgz' | sha256sum -c
(where the date "Wed, 11 Apr 2018 15:59:39 GMT" is from
`wget -S https://www.netlib.org/fp/dtoa.c`
"Last-Modified: Wed, 11 Apr 2018 15:59:39 GMT" header).
Change-Id: Ia61b7678e257c4bc1ff193f3f856d611aa5c1a21
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88854
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
CPython commit f40d4ddff3c800b3c956a5e8820aabe3aa87cddd "Closes #27979:
Remove bundled copy of libffi" causes a bit of a problem because it
turns out that libffi isn't all that stable; there's libffi.so.5 on
CentOS 6, libffi.so.6 on CentOS 7 and libffi.so.7 on
lo_daily_update_gandalf tinderbox.
So we have to bundle it in LO; it's only used on GNU/Linux currently.
CPython commit 32119e10b792ad7ee4e5f951a2d89ddbaf111cc5 "bpo-35947:
Update Windows to the current version of libffi (GH-11797)" also removes
the libffi for MSVC, so in a future python upgrade we will have to build
libffi for MSVC too.
The libffi fork for MacOSX is still in CPython git master.
(regression from b10be5d484)
Change-Id: Ibc20cf8cd3614cf9941b6970662bd930496776b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86493
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Skia's sk_app::WindowContext can create GPU-backed SkSurface only
for windows, but we also use virtual devices that are not windows.
Fortunately, SkSurface can be created GPU-backed from GrContext*
and sk_gpu_test::GrContextFactory seems to provide it easily.
It is not completely clear to me what the rules are on mixing
SkSurface's with different GrContext* (see the comment
in SkiaSalGraphicsImpl::copyBits()), but it seems to work fine.
Change-Id: I8110b67c41ab092e0c4b6a0973d6bed8a408c4c1
Not quite complete yet, missing e.g. Vulkan sources, and the setup
is not completely correct either.
Change-Id: I2283bf12f0d226ff8a34554deae5a7bd69045971
Noticed when executing CppunitTest_sccomp_solver that it apparently depended on
ExternalProject_lpsolve but not on ExternalPackage_lpsolve.
(LpSolverTest::testLpSolver in sccomp/qa/unit/solver.cxx instantiates UNO
service com.sun.star.comp.Calc.LpsolveSolver in Library_solver, which uses
lpsolve as an external.)
Thanks to mst for showing me the right place to fix.
Change-Id: I71a1c3552473ff6fea616805eea1fb68143d255b
Reviewed-on: https://gerrit.libreoffice.org/81133
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Since that variable holds the relevant includes, using
'gb_LinkTarget_set_include' makes sure that those
flags end up in the correct section, e.g. when generating
IDE integration using 'gbuild-to-ide', and thus prevents
issues like that described in
4aa6049062
("gbuild: treat $({QT,KF}5_CFLAGS) as cxxflags, not defines").
(Value of 'DCONF_CFLAGS' variable on Debian testing with
'libdconf-dev' 0.34.0-1 is:
DCONF_CFLAGS=-pthread -I/usr/include/dconf -I/usr/include/libmount
-I/usr/include/blkid -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include
)
Change-Id: I74c5194d88838bffa2b8515372266336627f235c
Reviewed-on: https://gerrit.libreoffice.org/79874
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Just as the gtk3 plugin isn't named GNOME, rename kde5 to kf5, as
it is based on the KDE frameworks 5 libraries.
This also includes:
* a convenience alias to load the kf5 VCL plugin in case someone
requests the kde5 plugin.
* keep convenience kde5 configure switch, but warn about it
* rename detected desktop from kde5 to plasma5
Change-Id: I6764a05b81a5edbf284484c234fee2649aacf735
Reviewed-on: https://gerrit.libreoffice.org/75313
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The flag has been introduced with commit
9335945c7c ("KF5 initial VCL plugin")
and was presumably just copy-pasted in commit
4d78cf97d7.
The flag should no longer be necessary now; the only issue showing
up after removing the flag was fixed.
Change-Id: I65fe4d12bdf7d5888b75f8a5743bab6979a63295
Reviewed-on: https://gerrit.libreoffice.org/73892
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Treat all of QT5_CFLAGS, QT5_GLIB_CFLAGS and KF5_CFLAGS as
C++ flags, since those contain C++ flags in the first place.
Therefore, set them using 'gb_Library_add_cxxflags',
not 'gb_Library_add_defs'.
(Strictly speaking, those variables contain includes as well,
but handling that properly would require splitting this
up further, either in 'configure.ac' or see e.g. how it's done
in 'RepositoryExternal.mk'.)
This also prevents the values of those variables from ending
up in the wrong section in IDE integration generated by
gbuild-to-ide.
Handling them as includes previously resulted e.g. in 'vcl/vcl.pro'
(generated by 'make qtcreator-ide-integration') containing
DEFINES += BOOST_ALL_NO_LIB \
... \
VCLPLUG_GTK3_KDE5_IMPLEMENTATION -isystem /usr/include//KF5 -isystem /usr/include//KF5/KCoreAddons [...]
and Qt Creator would show a (rather unhelpful) warning like the
following when opening a header file inside 'vcl/inc/':
> Warning: The code model could not parse an included file,
> which might lead to incorrect code completion and highlighting,
> for, example.
>
> 4:9: error: macro name must be an identifier
Change-Id: I2bb0c37fdf1112650e8adc712f60737888a8169b
Reviewed-on: https://gerrit.libreoffice.org/73699
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
KDE4 is out of maintenance upstream since Nov. 2014, and binaries
provided by TDF have switched to KDE5 as the official backend.
Change-Id: I165465b56d3ba3a18912b203c06ae8fc6111c0c9
Reviewed-on: https://gerrit.libreoffice.org/60014
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
buovjaga reported on IRC that his build (implicitly --without-system-harfbuzz
--without-system-icu) failed to link e.g. Library_vclplug_gtk3 due to harfbuzz
missing symbols from ICU, like
> /usr/bin/ld: /home/user/libreoffice/workdir/UnpackedTarball/harfbuzz/src/.libs/libharfbuzz.a(libharfbuzz_la-hb-icu.o): in function `hb_icu_unicode_decompose_compatibility(hb_unicode_funcs_t*, unsigned int, unsigned int*, void*)':
> /home/user/libreoffice/workdir/UnpackedTarball/harfbuzz/src/hb-icu.cc:334: undefined reference to `unorm2_getNFKDInstance_62'
[...]
It is not clear to me why Library_vclplug_gtk3 would actually use
libharfbuzz.a's hb_icu_unicode_decompose_compatibility (and for e.g. my builds,
it apparently doesn't), but in general libharfbuzz.a does depend on some symbols
from icuuc, so it is correct to add icuuc to the link when linking against
harfbuzz. (And "gb_LinkTarget_use_external,...,icuuc" conveniently only adds
libs for linking, and does not add C/C++ include file paths, which would not be
wanted here.)
(<https://gerrit.libreoffice.org/#/c/60882/> "Revert 'Add more more dependencies
to VCL makefiles'" was a false start trying to address the above issue.)
Change-Id: Ic8bcfa2aab185f8a9487d7787b4f22068e7cb481
Reviewed-on: https://gerrit.libreoffice.org/60898
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
And make all necessary adjustments for the new version of orcus.
Change-Id: I0dc207162a3ddfaad6da198a3d13b65f530757d5
Reviewed-on: https://gerrit.libreoffice.org/59884
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
since it has nothing to do with the headless command line option, so
use the name it has in the configure.ac file
Change-Id: Ibf0615ed02695d6e48a797f5632e4f417c010c70
Reviewed-on: https://gerrit.libreoffice.org/59611
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Additionally I erased the remains of the old mysql C++ connector.
Also update the code where the clang plugins were unhappy after moving
the mysqlc module.
Remove mysql-cpp-connector external.
Change-Id: I771cc7afacf5012fc349afb6b36828fb0fee5a66
Reviewed-on: https://gerrit.libreoffice.org/59200
Tested-by: Jenkins
Reviewed-by: Tamás Bunth <btomi96@gmail.com>
Miklos Vajna