and use SVG instead of PNG.
Link had been broken for more than a year.
Change-Id: I003c177f69630cd049a8d7df17bc4b02f45aa458
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166473
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Not sure how 02f48a3240 "Adjust for new linux
baseline" had decided to declare "Clang 12 with libstdc++ 8.5" sufficient for
building on Linux. But I just experienced that building recent master on Ubuntu
20.04 with its libstdc++ 9.4.0, against a (lode-built) Clang 12.0.1, failed with
> codemaker/source/commonjava/commonjava.cxx:45:21: error: no matching literal operator for call to 'operator""_ostr' with arguments of types 'const char *' and 'unsigned long', and no matching literal operator template
> { "void"_ostr, "java/lang/Void"_ostr },
> ^
etc., apparently because the use of std::copy_n in constexpr O[U]StringLiteral
ctors is not yet constexpr there. And
<https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B20_library_features>
indeed lists "P0202R3" (i.e.,
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0202r3.html> "Add
Constexpr Modifiers to Functions in <algorithm> and <utility> Headers") as only
available since "GCC libstdc++": "10".
Change-Id: I9d8ee2833f3b0c6c24059ec6e5d4dc8994058a1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164895
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(and would also be macOS 13 for the intel builds if the old macMini
would be on the officially supported list)
Change-Id: I4205f30274bdd43d80d02d6cda863ec83bdda63e
This gives us support for filesystem library
(after GCC is bumped to >7)
Change-Id: I5e497ee818de883e63e1288acfc400ebadf0cdec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144156
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
This gives us full support for variant, optional, any and visit libraries
Change-Id: I9f1bff5d7c0e2d5acc8c8b92c9a269b00e317574
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135804
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
As discussed in the ESC, although LibreOffice can be built with the
Java Development Kit (JDK) version 9, the JDK 9 is no longer
supported by the JVM vendors including Oracle, Red Hat and others.
Thus, it is asserted here that JDK 11 or later should be used to build
LibreOffice.
For further information on the supported versions of JDK, and its
lifcycle, see these articles:
Oracle Java SE Support Roadmap (Updated March 22, 2022)
https://www.oracle.com/java/technologies/java-se-support-roadmap.html
OpenJDK Life Cycle and Support Policy (Updated November 22 2021)
https://access.redhat.com/articles/1299013
It should be noted that JDK 8 is still supported, but it is not usable
for building LibreOffice.
It is also documented that without Java one may lose many features that
are described in the TDF wiki article Development/Java:
https://wiki.documentfoundation.org/Development/Java
Change-Id: Id001c341a221b0fe5c07c7129956a824261d32c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135557
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
During the compilation with Visual Studio 2019 v16.5, the dragonbox
was failing the build, but it was OK when ugprading to the latest
version, 16.11.
It should be noted that according to the list of predfined macros in
Visual Studio, v16.10 and v16.11 use the same value for _MSC_VER,
which is 1929. Thus, the distinction between these 2 versions can not
be distinguished.
Predefined macros
https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros
For not having the Visual Studio version > 16.10, a warning is
shown, and if the Visual Studio version is < 16.5, just like before,
an error is generated.
Change-Id: I6661ee5121b03ca43e1f7503b74191abcc8d6b40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132907
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
My Kate editor decided to do some whitespace cleanup, but maybe
it's fine as the main changes are not targeting functional bits anyway.
Change-Id: I5292e77e43055f94a6256a7f72d49fd59287d194
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132928
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
* Updated README.md contents to fix various issues
* Fixed source links by using [git:], processed by mkdocs scripts
* Added README.md for ios, setup_native, unotest
* Fixed issues with "underline" and "less than" sign
Change-Id: I3e52a1d3372586c390ee6c42a2ef48bbabc81398
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114248
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
After b4b7e92cbf "Use MSVC's /permissive- to make
it more standards conforming", vmiklos reported that his 16.4.6 build started to
fail with
> C:/lo/master/connectivity/source/drivers/odbc/OStatement.cxx(411): error C2760: syntax error: unexpected token 'identifier', expected 'type specifier'
> C:/lo/master/connectivity/source/drivers/odbc/OStatement.cxx(411): note: This diagnostic occurred in the compiler generated function 'T connectivity::odbc::OStatement_Base::getStmtOption(SQLINTEGER) const'
> C:/lo/master/connectivity/source/drivers/odbc/OStatement.cxx(418): error C2760: syntax error: unexpected token 'identifier', expected 'type specifier'
> C:/lo/master/connectivity/source/drivers/odbc/OStatement.cxx(418): note: This diagnostic occurred in the compiler generated function 'SQLRETURN connectivity::odbc::OStatement_Base::setStmtOption(SQLINTEGER,T) const'
> [build CXX] connectivity/source/drivers/odbc/ODatabaseMetaData.cxx
> make[1]: *** [C:/lo/master/solenv/gbuild/LinkTarget.mk:301: C:/lo/master/workdir/CxxObject/connectivity/source/drivers/odbc/OStatement.o] Error 2
> make[1]: *** Waiting for unfinished jobs....
> C:/lo/master/connectivity/source/drivers/odbc/ODatabaseMetaDataResultSet.cxx(161): error C3861: 'checkDisposed': identifier not found
> C:/lo/master/connectivity/source/drivers/odbc/ODatabaseMetaDataResultSet.cxx(161): note: 'checkDisposed': function declaration must be available as none of the arguments depend on a template parameter
> C:/lo/master/connectivity/source/drivers/odbc/ODatabaseMetaDataResultSet.cxx(161): note: This diagnostic occurred in the compiler generated function 'T connectivity::odbc::ODatabaseMetaDataResultSet::getInteger(sal_Int32)'
> make[1]: *** [C:/lo/master/solenv/gbuild/LinkTarget.mk:298: C:/lo/master/workdir/CxxObject/connectivity/source/drivers/odbc/ODatabaseMetaDataResultSet.o] Error 2
while it succeeded after upgrading to 16.8.4. That change had been seen working
with 16.5.4 (on tb73, see
<https://lists.freedesktop.org/archives/libreoffice/2021-January/086635.html>
"Heads up: Use MSVC's /permissive- to make it more standards conforming"), so
lets hope that bumping the baseline from 16.4 to 16.5 is all that is needed.
Change-Id: I7446f778a94e15e7ea5c8ef0780bf10831a2d4b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109293
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(where 16.4 is currently the latest version of Visual Studio 2019 available at
<https://visualstudio.microsoft.com/downloads/>), see
<https://lists.freedesktop.org/archives/libreoffice/2020-February/084575.html>
"ESC meeting minutes: 2020-02-27": "Update baseline to VS2019 on master before
7.0 [...] check what’s the current patch level, require that? [...] no
objections"
The code from 4ea0059bca "VS detection: Fallback
to old registry check if vswhere failed" has been removed in accordance with its
comment "The below hack does not work for VS 2019 anyway, so should be removed
when upgrading baseline.
(Changing the comment "go to Start menu, open 'Visual Studio 2017', [...]"
regarding the installation of GNU Make from source is somewhat arbitrary, but
lets stick to the tradition of bumping that version number along with any build
baseline bump.)
Change-Id: Ic4fe8a3d347aa1748377f2d3205e302bff189b79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89699
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
configure.ac doesn't check for any version as far as I see, add what
works for me at the moment.
Change-Id: If8b28e2a5d4bf4aea4325038ddf416a43f904db4
Reviewed-on: https://gerrit.libreoffice.org/81621
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The baseline info was silent on Android, and at least my old r16b was
too old to build master, while updating to r19c fixes the build, so
document that finding.
Change-Id: I8713d68a9cfe62ca241f0047f46da496acb85acd
Reviewed-on: https://gerrit.libreoffice.org/78119
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
...to match configure.ac check from 206b8c4ae3
"On Windows, check for at least Visual Studio 2017 version 15.7"
Change-Id: Ie78beb0a1d57aea590f3e73b9d4c45787d6531bf
Reviewed-on: https://gerrit.libreoffice.org/77488
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...as discussed at
<https://lists.freedesktop.org/archives/libreoffice/2018-November/081435.html>
"minutes of ESC call ...".
This no longer sets CLANGVER, CLANG_VERSION, and CLANG_FULL_VERSION when using
Apple Clang (on macOS), which uses different version numbers from upstream
anyway. But those variables are only used in the context of compiler plugins,
which do not work with Apple Clang anyway (which lacks necessary include files).
(Also, move "AC_SUBST(COM_IS_CLANG)" up to where it belongs.)
Change-Id: Iee37c42ecacf52fa5a07e35241bcd404025e1cdf
Reviewed-on: https://gerrit.libreoffice.org/63899
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It is much over a year since we bumped to 10.9, so it is time.
Bumping to 10.10 will allow us to with good conscience get rid of some
code that (presumably) tries to emulate some aspects of OS X user
interface look that went away in 10.10. See tdf#114839.
Change-Id: Ic41f73d8e59a40c4696069af85bb3ff33146086c
Reviewed-on: https://gerrit.libreoffice.org/63880
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Not sure why we at some stage lost the possibiliy to build against any
of several recent versions, but require one specific. But yeah, no big
deal, anybody working on iOS code is expected to keep ther Xcode (and
thus SDKs) updated.
