summaryrefslogtreecommitdiff
path: root/external/cppunit
AgeCommit message (Collapse)Author
2024-05-10help msvc -analyzer out wrt CPPUNIT_ASSERTCaolán McNamara
so it can code following the CPPUNIT_ASSERT doesn't need to check what condition might have failed in the assert Change-Id: Ife7e5e54b17a8316425222d2a0efd694c9467089 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167480 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins
2024-01-06cid#1546421 COPY_INSTEAD_OF_MOVECaolán McNamara
Change-Id: Ifab2f2f5ec8c7f41cd705e0fb07d1273a34b879d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161724 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-06cid#1545475 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1545626 COPY_INSTEAD_OF_MOVE cid#1546203 COPY_INSTEAD_OF_MOVE Change-Id: I98a6c36e77fe633d50fdb1a0f063b2656f852a2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161718 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-02cid#1545836 COPY_INSTEAD_OF_MOVECaolán McNamara
Change-Id: Idb754296175f786c7850253749e3b7f968aa87fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161525 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-30cid#1546460 COPY_INSTEAD_OF_MOVECaolán McNamara
Change-Id: I562eea9548929f11de2a2b68bba09ae3a777ffe3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161456 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-02-21Mark recently added external/cppunit/*.patch.0 as upstreamedStephan Bergmann
Change-Id: I62c62ee6fbd8ec6bf1846cea305ab97d4e567ae0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147385 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-20external/cppunit: Don't mis-apply GCC < 4.6 workaround for ClangStephan Bergmann
...which happens to define __GNUC__=4, __GNUC_MINOR__=2 Change-Id: I128547d0bd375ffec9deb6abd744eeb2667ba666 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147257 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-20external/cppunit: Use snprintf instead of sprintfStephan Bergmann
...to avoid > workdir/UnpackedTarball/cppunit/include/cppunit/TestAssert.h:115:8: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations] > sprintf(buffer, "%.*g", precision, x); > ^ > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here > __deprecated_msg("This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.") > ^ > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg' > #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg))) > ^ on macOS after the upcoming <https://gerrit.libreoffice.org/c/core/+/147257> "Don't mis-apply GCC < 4.6 workaround for Clang" Change-Id: I213de1d112cb56fba220006842e611c56ccc7331 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147333 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-13Mark external/cppunit/propagate-exceptions.patch.0 as upstreamedStephan Bergmann
Change-Id: I847b682c2823dcaf523f361044105e91462fbc3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144075 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-10Introduce CPPUNIT_PROPAGATE_EXCEPTIONS environment variableStephan Bergmann
Often a developer debugging a failing CppUnit test wants a core dump with the place where an uncaught exception is thrown. So if the newly introduced CPPUNIT_PROPAGATE_EXCEPTIONS environment variable is set (to any value), disable all the protectors that would otherwise catch such exceptions (and just report some limited information about them). Change-Id: I3052f71c0787583c496279a6f5b35a0299c357b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143882 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-29accept Apple's patch utility - pickier than GNU patch, but should be OKChristian Lohmaier
macOS Ventura replaced the patch utility by Apple's version: patch 2.0-12u11-Apple (as of macOS 13.0.1) It is picker/less robust when it comes to locating matches, and absolutely refuses to apply when the hunks are out of order. Only one patch needed rework in the current codebase (master an 7-4 branch), and being more correct about the locations in the files to be patched is not a bad thing either, so accept Apple's version of patch (with a warning for now) Change-Id: I707d00958b814307b13caf9923f1de7f3919442c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143461 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2022-03-30WASM fix native EH build since Emscripten 3.1.6Jan-Marek Glogowski
Building LO with WASM native EH and Emscripten 3.1.6+, the link fails with a missing "emscripten_longjmp" symbol. Actually the old build was simply wrong, because the emscripten_longjmp function is just used for the Emscripten SjLj and not the native WASM SjLj implementation. Linking just worked, because the used libcompiler_rt-wasm-sjlj-mt.a lib was incorrectly providing that symbol, which 3.1.6 removed. But since running the NEH build still fails early in the same way then before in FF nightly 100 and Chrome (= failure in the LO job scheduler calling Task::UpdateMinPeriod for the "desktop::Desktop m_firstRunTimer" timer, resulting in a WASM VM "RuntimeError: indirect call signature mismatch"), there is still no way to know, if nothing else it missing. The Emscripten / JS EH build still works without any code changes. And it's not the first call on a job object that fails... And unfortunatly, because Qt itself also uses libpng, it also uses SjLj for error handling, like LO in the image import, so the Qt build must also be patched to build with "-s SUPPORT_LONGJMP=wasm". Simply enough to do (see README.wasm.md). LO's configure now detects that symbol and will bail out on incompatible Qt and LO build setup. See https://github.com/emscripten-core/emscripten/issues/16572 Change-Id: I3a1877f3aeb77873906176b9d3cd1ea92973f1f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132139 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-31externals: always provide platform configure flagsJan-Marek Glogowski
No idea why we just provided the platform flags when cross- compiling. In the curious case, where the host platform is detected as x86_64-pc-mingw32 per default and we actually want to override it with x86_64-pc-cygwin, we don't do a cross compile, but must override the host platform. But there is additional special handling needed for the omitted cross-platform build in the special case of --host=i686-pc-cygwin and --build=x86_64-pc-cygwin, where we deliberatly ignore cross building; Windows is already a slow build, so try to keep this optimization (AMD64 can execute x86 binaries). There is the theoretical case, where the externals config.guess would have detected something else and that "magically" even worked, while the LO detected triplet would fail, but this should be fixed in the external in any way. Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-11-04Consolidate -D_GLIBCXX_DEBUG for --enable-dbgutil builds against libstdc++Stephan Bergmann
(this was meant as a prerequisite for enabling its -D_LIBCPP_DEBUG=1 counterpart when building against libc++ on macOS, but which got stalled for now after running into the issue described at <https://lists.llvm.org/pipermail/libcxx-dev/2021-October/001222.html> "[libcxx-dev] Building a program with -D_LIBCPP_DEBUG=1 against a libc++ that is not itself built with that define") Change-Id: If466dce595a9311b2afbae41d5ddcaecc6f3c57b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124678 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-21Mark external/cppunit/order.patch.0 as upstreamedStephan Bergmann
Change-Id: Ic0bfacd74e007c979d574e65767cbfb0d40c9ef7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123965 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-08Centralize VS-to-toolset mapping in configureMike Kaganski
This allows to define the mapping once, and avoid modification in multiple places each time a new VS version support is added Change-Id: I93de4c9d78c3f67a0a2e157007e9d13b6f557937 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123163 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-16Add preliminary VS 2022 supportHossein
This patch changes the configure.ac, so that LibreOffice compiles with the latest VS 2022 preview. The option --with-visual-studio=2022 should be added to the autogen.input, in order to use VS 2022 preview. Change-Id: Ia1d9bbeabbbd44ffe82af3624151b69d36c0a45c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122133 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-05-05WASM: add initial support for Emscripten cross buildJan-Marek Glogowski
- configure with: - --host=wasm64-local-emscripten - had to make a few externals optional, so adding: - --disable-nss - --disable-cmis - --disable-curl Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2020-09-17cppunit: fix Windows Arm64 buildJan-Marek Glogowski
Change-Id: I75b169362ed703bcae0720aeac0602f389435317 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102857 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-15WIN add and apply default msbuild platform+configJan-Marek Glogowski
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>
2020-08-08external/cppunit: Run tests in deterministic orderStephan Bergmann
What prompted me to make this change is that when I tried an --enable-lto build, CppunitTest_xmlsecurity_signing failed in a non-obvious way, and I noticed that it ran the individual tests in a different order than a --disable-lto build. With this change, CppunitTest_xmlsecurity_signing also started to fail in the --disable-lto build, which has meanwhile been fixed with 800eebfa82106c509310ed43bef38a7a4ad4451f "Database document apparently needs to be closed before it is disposed". No other tests started to fail in my Linux --disable-lto-build with this change, and my Linux --enable-lto build (using recent Fedora 32 GCC 10.2 and the default linker) also succeeds `make check` after 800eebfa82106c509310ed43bef38a7a4ad4451f, both with and without this cppunit change. (<https://bugs.documentfoundation.org/show_bug.cgi?id=126442> "LTO build segfaults in sw_apitests" and <https://src.fedoraproject.org/rpms/libreoffice/c/ 5d644f1606b76ffa4a102433849a824d7293a404> "%check fails with lto enabled" indicate that older branches also fail CppunitTest_sw_apitests with --enable-lto, but I could not reproduce that on current master.) What happens in cppunit is that every CPPUNIT_TEST_SUITE_REGISTRATION (or other macro like CPPUNIT_TEST_FIXTURE internally calling CPPUNIT_TEST_SUITE_REGISTRATION) creates a global static variable whose ctor inserts the address of a sub-object of that global static variable into the TestFactoryRegistry::m_factories set. Even if the order of invocation of those ctors from one .cxx is deterministic, the relative order or the addresses of those sub-objects inserted into the TestFactoryRegistry::m_factories set need not be (though they probably typically are). Another source of nondeterminism is that the order of ctors from different .cxx is not specified (which might have caused the CppunitTest_xmlsecurity_signing failures, given that test includes suites from two different .cxx). So to make test execution more reproducible, make the order in which the tests are run deterministic, sorting them by name. (When TestFactoryRegistry::addTestToSuite the adds the sorted tests to TestSuite::addTest, they are inserted into a TestSuite::m_tests vector, from which point on things appear to already happen in a deterministic order.) Change-Id: I40741f397a96772974fd41bacdb3dd763c885417 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100384 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-07external/cppunit: -g based on --enable-symbols, not --enable-debugStephan Bergmann
Change-Id: I35ceb0069082cb66f1bc09591baace594f0dc030 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100297 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-03-04Bump Windows build baseline to Visual Studio 2019 16.4Stephan Bergmann
(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 4ea0059bca6dd84f10abcf52f6d6b81c1afec397 "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
2020-02-16GBUILD_TRACE, support for finding out where the build time is spentLuboš Luňák
See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-12-24update cppunit to 1.15.1Markus Mohrhard
Change-Id: Ic27a77addb409a8d63ea44136a8d2410ee40c4d2 Reviewed-on: https://gerrit.libreoffice.org/85539 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2019-04-16Initial VS 2019 SupportTomoyuki Kubota
Change-Id: I8e08efb549ebd52c37183a1185d6de73f2b00601 Reviewed-on: https://gerrit.libreoffice.org/64630 Reviewed-by: himajin100000 <himajin100000@gmail.com> Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> Tested-by: Michael Stahl <Michael.Stahl@cib.de>
2019-02-01Better fix for missing [[noreturn]] of CPPUNIT_FAILStephan Bergmann
This includes a revert of commit 9808486a89c6368f836579f8d8c0dda63fd0063c "Avoid -Werror,-Wimplicit-fallthrough with clang-cl", and also undoes older MSVC workarounds (that would start to cause "warning C4702: unreachable code" now). Change-Id: If72bf336e12e0a2db589857e8875003dae861977 Reviewed-on: https://gerrit.libreoffice.org/67248 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-16Minimum Supported Version is VS2017himajin100000
Change-Id: Id771f1fe0d8c6702a52836f6229a944d259fed4c Reviewed-on: https://gerrit.libreoffice.org/66424 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-11-01gbuild: rename value OS=IOS to OS=iOSMichael Stahl
This gets rid of the horrible hack in gbuild.mk to accomodate the case-incorrect iOS platform makefiles that cannot be renamed without upsetting git on file systems that sadly lack the case sensitivity feature. Keep the macro defined to IOS though. Change-Id: I1022bfef4900da00e75fc1ccce786b20f8673234 Reviewed-on: https://gerrit.libreoffice.org/62705 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2018-09-27Do build cppunit for iOS, tooTor Lillqvist
I am writing a separate unit test app that will include selected existing unit tests that make sense and are important to run on iOS. Change-Id: I4722f1ed872ba21e181eeba5ed3b58e82d8fed72 Reviewed-on: https://gerrit.libreoffice.org/61049 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2018-08-07Mark external/cppunit/gcc9.patch.0 as addressed upstreamStephan Bergmann
Change-Id: I9071acc34d07f3819fb40c93bbee6b5bcc79a14a Reviewed-on: https://gerrit.libreoffice.org/58691 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-07-26external/cppunit: silence -Werror=deprecated-copy (GCC trunk towards GCC 9)Stephan Bergmann
Change-Id: I2daec11938361a6988741bd29e713a36a4c77414 Reviewed-on: https://gerrit.libreoffice.org/58042 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-06-29cppunit: also build 64-bit DLL always with PDB fileMichael Stahl
Note: this maps to /Z7 apparently: <DebugInformationFormat>OldStyle</DebugInformationFormat> https://msdn.microsoft.com/en-us/library/bb629394.aspx lists various options but passing /p:DebugSymbols=true /p:DebugType=full /p:PdbFile=... to msbuild.exe by itself doesn't do anything while patching the project file works. Change-Id: I888b5f6af7be519e2d35b749873ae7d35bb0bf9d Reviewed-on: https://gerrit.libreoffice.org/56605 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-01-18android: use unified headers and llvm-c++ STL (x86) with NDK 16Christian Lohmaier
gnustl (and others) are to be removed in future versions of the ndk also bump gradle and build-tools to current versions along with it arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix that later Change-Id: Ic794c3293b599b77ec48096bf3283a99c09cbb79 Reviewed-on: https://gerrit.libreoffice.org/45163 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2017-07-15builds externals without werrorCaolán McNamara
I get a warning under MacOSX of argument unused during compilation -I . -Werror,-Wunused-command-line-argument Change-Id: I0ae48783eefa52a829471e51a94c79d235dc2f38 Reviewed-on: https://gerrit.libreoffice.org/39988 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-05-30sal,external: remove checks for obsolete VCVER=120Michael Stahl
Change-Id: I4d32b7c4b2e545a8d979bc516f64cfcbf66ecd07
2017-04-14update cppunit to 1.14.0Markus Mohrhard
Change-Id: I95fa42f4ef0580734b605df859c1660b29adb8b2 Reviewed-on: https://gerrit.libreoffice.org/36499 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2017-02-22MSVC 14.0: Make it work with older SDK versionDavid Ostrovsky
Change-Id: I50a9e8b122250af445c2a1b3d0941d508e027318 Reviewed-on: https://gerrit.libreoffice.org/34528 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Ostrovsky <david@ostrovsky.org>
2017-02-21Fix check for non-empty UCRTVERSIONStephan Bergmann
...introduced with b862cbdd345ec57c2595629ded6a3969e1e65d56 "Support MSVC 15.0", but $(filter ...,) always expands to the empty string, and this is probably what was intended. Change-Id: I5865ea13ba3c3d52402bcba48f4f770f6c2b8862 Reviewed-on: https://gerrit.libreoffice.org/34482 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-02-15Support MSVC 15.0David Ostrovsky
New compiler changes quite some stuff: * Compiler detection done based on different registry key * .NET SDK detection done based on different registry key * Msbuild installation directory changed * Merge modules installation directory changed * SDK number in registry doesn't match the directory name: (registry key: 10.0.14393, directory name: 10.0.14393.0) * Compiler, include and library location directories changed * Architecture specific directory changed: x64 instead of amd64 * Compiler own include directory must be added with -I option * To force usage of SDK 10 (8.1 is selected per default) new switch WindowsTargetPlatformVersion is passed to msbuild, to avoid patching VC project files with this line: <WindowsTargetPlatformVersion><SDK>/WindowsTargetPlatformVersion> Known issues: * Firebird is broken: http://paste.openstack.org/show/594333 Change-Id: I148d7932aff43bbbd07bd493504df974726234c2 Reviewed-on: https://gerrit.libreoffice.org/31279 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Ostrovsky <david@ostrovsky.org>
2017-02-10Remove MinGW supportStephan Bergmann
In OOo times, there'd originally been efforts to allow building on Windows with MinGW. Later, in LO times, this has been shifted to an attempt of cross- compiling for Windows on Linux. That attempt can be considered abandoned, and the relevant code rotting. Due to this heritage, there are now three kinds of MinGW-specific code in LO: * Code from the original OOo native Windows effort that is no longer relevant for the LO cross-compilation effort, but has never been removed properly. * Code from the original OOo native Windows effort that is re-purposed for the LO cross-compilation effort. * Code that has been added specifially for the LO cross-compilation effort. All three kinds of code are removed. (An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing --with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.) Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568 Reviewed-on: https://gerrit.libreoffice.org/34127 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2015-09-09externals: remove various obsolete MSVC2012 specific flagsMichael Stahl
Change-Id: I8848d042a008c21e407d9610161b5c67d2137a18
2015-09-02Fix cppunit on MSVC 14.0David Ostrovsky
Change-Id: Iebfbd843cd3fbe46f3e090654a8493adb5309800 Reviewed-on: https://gerrit.libreoffice.org/17341 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2015-01-26external/cppunit: Visible function type RTTI for Clang -fsanitize=functionStephan Bergmann
Change-Id: Ie2a6e993b7982629aed650d6534a09a9eefe1c51
2014-12-15realityTakeshi Abe
Change-Id: I498507ad7d951a71f7be2c0d3c411756e0462f7d
2014-11-03add some more kill paths to cppunitCaolán McNamara
Change-Id: I8610e99aecc725e349976746af6c8bd560ba2ffa
2014-08-14upgrade to cppunit 1.13.2Thomas Arnhold
* remove obsolete patch part * enable x64 target for vc project file on win64 Change-Id: Ie794c08c9f739ad8c9c68c423f72e79ed4f6b0ff Reviewed-on: https://gerrit.libreoffice.org/10856 Reviewed-by: Thomas Arnhold <thomas@arnhold.org> Tested-by: Thomas Arnhold <thomas@arnhold.org>
2014-08-09VS2013: Override ToolsVersion settingThomas Arnhold
Otherwise those external projects will fail, because with only VS2013 installed there is no ToolsVersion 4.0 (which is set inside the VC projects files). http://msdn.microsoft.com/en-us/library/bb383985.aspx Change-Id: I144ba1ef95372226ebadb082e3a78155cca316fd
2014-07-11VS2013: Adjust cppunit to 12.0 vcproj versionDavid Ostrovsky
Change-Id: I9223fc0620bf31389ab4ea0971835dd7a27feb7e Reviewed-on: https://gerrit.libreoffice.org/10159 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2014-07-07Handle VCVER==120 (VS 2013) tooTor Lillqvist
Change-Id: I4dbf663790bd8906ef8b123a01bdf52e0c0c1962
generated by cgit (git 2.34.1) at 2025-01-10 22:00:40 +0000