and
cid#1660117 Variable copied when it could be moved
cid#1659985 Variable copied when it could be moved
cid#1659983 Variable copied when it could be moved
cid#1659982 Variable copied when it could be moved
cid#1659973 Variable copied when it could be moved
cid#1659956 Variable copied when it could be moved
cid#1659955 Variable copied when it could be moved
Change-Id: Icc0f2f4a37fa8eb4c874dfd842650067c186466b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189255
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and
cid#1660326 Variable copied when it could be moved
cid#1660325 Variable copied when it could be moved
cid#1660324 Variable copied when it could be moved
cid#1660321 Variable copied when it could be moved
cid#1660320 Variable copied when it could be moved
cid#1660316 Variable copied when it could be moved
cid#1660313 Variable copied when it could be moved
cid#1660307 Variable copied when it could be moved
Change-Id: I9fe4fa56693f8e3a1efd47294ecb7e0e5588b9b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188851
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Most of these don't use boost themselves, nor do they need
it transitively since the use of boost::optional was removed
Change-Id: Ic9dee1c4e160b313ec5b91677b02ffdea6c5779d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164440
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
what I'm really after is some vexating not-reproducible oss-fuzz msan
warnings when using libxml2 in the fodt2pdf fuzzer. So lets upgrade
libxml2 to the latest, which requires bumping libxslt, and then requires
a newer liblangtag because of no longer implicit includes that it
depended on.
xmlKeepBlanksDefaultValue and xmlSubstituteEntitiesDefault are
deprecated, we should get around to updating those uses
Change-Id: I8fda0dffda0a7ea65407d246a3121875cb8ad4a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161598
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Our embedded clucene by default write a random current-time
millisecond value into version fields, in an attempt to
randomise. Clearly this is not needed for our static help, and it also
prevents builds from being reproducible.
Change-Id: I011388b5bc72b5d86bc1900f5439036ede60c020
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158845
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Seen in a fedora:40 container, using --with-system-libcmis,
--with-system-liblangtag and --with-system-xmlsec.
Change-Id: I9d748d3dc0b70dbfdfcb6b99c9ce8440bda6f326
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159980
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
E.g., a path like
C:\lo\src\build\instdir\program\..\program\..\user\extensions\bundled\registry\com.sun.star.comp.deployment.help.PackageRegistryBackend\lu149121qyy8a.tmp\da\help.idxl
would become 22 characters shorter:
C:\lo\src\build\instdir\user\extensions\bundled\registry\com.sun.star.comp.deployment.help.PackageRegistryBackend\lu149121qyy8a.tmp\da\help.idxl
Change-Id: Id6d397fdd7a1771225eef2e7e49ddb80802685b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156947
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Just build it if HELPTOOLS or XMLHELP are in BUILD_TYPE. And
simply tets for clucene just in this case. And since XMLHELP
is not in the list of PERMITTED_BUILD_TARGETS, disable it.
Change-Id: I13fdbf096c60191a428e23c22344f7e22e8c5d66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127231
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Regression from commit 14069d8417
("configure: Improve help-options handling").
We now must forward the help and extension configure options, as
this is needed by the cross toolset to know, if it needs to build
the HelpIndexer and HelpLinker executables.
Also get rid of gb_Helper_optional_for_host. While it's in theory
more correct, it makes gb_Helper_optional more complex, so we now
rely on the fact, that the config_build.mk BUILD_TYPE is a subset
of the config_host.mk BUILD_TYPE.
This should fix the Windows Arm64 build, which currently seem to
be the only cross-build including help.
Change-Id: I8b90923c891b43cd2655b2578015c9bd579aae7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117758
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This patch includes:
* A README.help.md as a general documentation for the different
help types, the LO code and help-related build options.
* Adds --disable-xmlhelp for removing the xmlhelp support from the
build. Disable for iOS, Android and Emscripten. This was partly
included in HAVE_FEATURE_DESKTOP before.
* Rename WITH_HELP define to WITH_HELPPACKS, which reflects the
actual usage AFAIK.
* Depend --with-omindex on --with-help=online and don't override
the --with-help setting. Error out on conflicting options.
* Depend --with-helppack-integration on build help variants, which
actually result in help packs.
Kind of reverts commit 2c38ea6d16
("Building without --with-help is not supposed to disable help
functionality").
Change-Id: Ie4cb73905b3ed94e991d9f1bd75cfbd6de9da385
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116222
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Lucene does not accept Unicode paths; it uses thread encoding. On
Windows, that makes it fail for any path that contains characters
not representable in ACP. Using short path name tries to workaround
that when first attempt has failed.
Since Windows 10 build 17134, the UCRT supports using a UTF-8 code
page: see
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale.
This has benefit of using Unicode, but I hesitate using it, since I
am not sure if setting the locale globally to UTF8 is a good idea
(what side effects may it have on other external libraries or our
use of CRT functions, when thread encoding differs from C locale?),
and if only setting it at object creation, it would crash later,
when attempting to access the stored Unicode path with restored old
locale.
Change-Id: I6a3a5a84ba54d8046ec011989289c9c7d5fa5c92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108484
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Andrea Gelmini