new baseline on Jenkins is using wsl-as-helper style build and Visual
Studio 2022. CI will use Winodws Server 2025, release builds will use
Windows 11 Pro.
biggest change for CI (apart from using VS2022) is the switch to doing
64bit builds instead of 32bit ones
Also update README.md accordingly.
Removal of cygwin support is not planned at the moment/in the near
future (but is also no longer actively covered by CI)
Support for Visual Studio 2019 will be dropped once code makes use of
features only covered by Vsual Studio 2022 or newer
Change-Id: I52b80433f985b081a57a24d7ccbf4c3c6d432935
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192159
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
The old Xcode version just doesn't support newer c++ features like
std::ranges and similar that some externals and now also some parts in
core start using.
We don't have any CI bots building on that old platform anymore, and
bumping the build-requirement doesn't affect the runtime requirements.
So instead of stacking on workaround after workaround for an OS that
already reached EOL, just drop support for building on it.
(see also https://developer.apple.com/xcode/cpp/ )
Change-Id: I340180f32c195547a1f93d271e5bbc59252198e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185895
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
that was already our documented baseline, but configure still accepted
older versions of the macOS SDK/older versions of Xcode.
Xcode 14.2 is the last version available for macOS 12 and it comes with
macOS SDK 13.1, so we can also require/check for that in configure.
After f4bd60261e
"Refactor comparison operators for DateTime and Time classes"
building with SDK 12.1 fails with
In file included from /Users/libreoffice/lode/bibisect/core258/tools/source/datetime/datetime.cxx:19:
/Users/libreoffice/lode/bibisect/core258/include/tools/datetime.hxx:74:69: error: invalid operands to binary expression ('pair<typename __unwrap_ref_decay<int>::type, typename __unwrap_ref_decay<long>::type>' (aka 'pair<int, long>') and 'pair<typename __unwrap_ref_decay<int>::type, typename __unwrap_ref_decay<long>::type>')
return std::make_pair(GetDate(), GetTime()) <=>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
Change-Id: I340180f32c195547a1f93d271e5bbc59252198e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179972
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
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
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>
* 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>
elioperdreau
Ilmari Lauhakangas