summaryrefslogtreecommitdiff
path: root/dbaccess/util/dba.component
AgeCommit message (Expand)Author
2015-12-12tdf#74608 dbaccess: Constructor for singleton DataAccessDescriptorFactoryMatúš Kukan
2015-12-05tdf#74608 dbaccess: Constructor feature for ODatabaseDocumentMatúš Kukan
2015-12-05tdf#74608 dbaccess: Constructor feature for OComponentDefinitionMatúš Kukan
2015-12-05tdf#74608 dbaccess: Constructor feature for OCommandDefinitionMatúš Kukan
2015-12-03tdf#74608 dbaccess: Constructor feature for ODatabaseSourceMatúš Kukan
2015-02-09dbaccess: use constructor feature for ORowSetMiklos Vajna
2013-12-19A singleton is not a serviceStephan Bergmann
2013-12-17Adapt all (non-extension, SharedLibrary) .components to environment="..."Stephan Bergmann
2012-06-14re-base on ALv2 code.Michael Meeks
2012-02-10dbaccess: DatabaseDataProvider is not in chart2Miklos Vajna
2011-07-13Add prefixes for component_getFactory methodsMatúš Kukan
2010-09-14sb129: #i113189# removed obviously unnecessary service registrations; allow e...sb
2010-09-10sb129: #i113189# change UNO components to use passive registrationsb
generated by cgit (git 2.34.1) at 2025-02-28 15:29:59 +0000
cgit/lo/core/commit/external/lcms2?id=ea68de2968c0dbcd8e7549435e829db06795c16d'>use gb_DEBUGINFO_FLAGS consistently in gbuild ExternalProject'sLuboš Luňák A number of them didn't use it at all, others had it hand-written in various ways. Change-Id: Iaf86325f9cdc032926bac917dc3eef4e34661544 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132818 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 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-10-20upgrade lcms2 to 2.12Caolán McNamara Change-Id: I40c3239495c6050add3ce2343453241f8c825d62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123886 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@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-17lcms2: fix Windows Arm64 buildJan-Marek Glogowski Adds the ARM64 platform to the VC2019 MSBuild solution. This turned out to be tricky, because - for whatever reason - diff couldn't detect the solution file as text, so I added the whole file to replace it. And "-a" would just generate a UTF-16 diff, which is not applyable, so this just adds the new file and copies it. Change-Id: I538610bed071fd45dc107f405056f23e1bff7a09 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102855 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-07-17lcms2: update to 2.11 and use VC2019 solutionJan-Marek Glogowski Dropped patches: - lcms2-msvc-disable-sse2.patch.1: applied to the VS2010 solution; so actually long unused by LO. - 0017-Upgrade-Visual-studio-2017-15.8.patch.1: not used anymore, because the Windows build now uses the VS2019 solution. The new external/lcms2/c++17.patch.1 explicitly disables the register keywordin the header. Change-Id: Icc6dd2a41d0fc94f00fc1ac7fa5bebc941c2a791 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98734 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> 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-10-16Allow building lcms2 with Windows SDK 8.1Mike Kaganski Change-Id: I81052f7634c7873d893d67deb79ed7bfa6dcbc44 Reviewed-on: https://gerrit.libreoffice.org/80888 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> 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-01-24Drop unnecessary gb_DEBUG_CFLAGSStephan Bergmann ...which was at maximum set to GCC's -finline-limit=0 -fno-inline (solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug builds "since forever", but that looks very much like cargo cult: -fno-inline "is the default when not optimizing" anyway (<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline (and maybe was present for ancient compilers that only supported -finline-limit but not -fno-inline?). Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874 Reviewed-on: https://gerrit.libreoffice.org/66836 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> 2019-01-16lcms2: upgrade to release 2.9Michael Stahl ... at least, that's the plan - this is harder than it appears, as the upstream maintainer appears to have released version 2.9 at least 3 times: - Fedora has a file evidently downloaded before Nov. 17 with SHA512 of e30ad5a9a1ab9e7aaace9431434caa19a5ff6143db46644aba971a5ee37a265b26bf738e886d766405a7eb45a9d620d67c7ab3684ace86a107cf5a76642c04a5 - Gentoo has a file evidently downloaded before Nov. 19 with SHA256 of d4ad6f8718f7f9dc8b2a3276c9f237aa3f5eccdcf98b86dedc4262d8a1e7f009 - Debian has a file evidently downloaded before Dec. 17 with SHA256 of 48c6fdf98396fa245ed86e622028caf49b96fa22f3e5734f853f806fbc8e7d20 The lcms2-2.9.tar.gz available from sourceforge currently matches the one Debian has, so let's use it. * 0017-Upgrade-Visual-studio-2017-15.8.patch added (fixing CVE-2018-16435) * 0001-Added-an-extra-check-to-MLU-bounds.patch.1 removed (fixed upstream) Change-Id: Iab8dada8f6d77d5b2da8560993380b3332bc02f6 Reviewed-on: https://gerrit.libreoffice.org/66400 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> 2017-11-07external/lcms2: Stop warnings/errors about "register"Stephan Bergmann ...when workdir/UnpackedTarball/lcms2/include/lcms2.h is included from workdir/UnpackedTarball/pdfium/core/fpdfapi/page/cpdf_colorspace.cpp (Library_pdfium). Even with -std=gnu++17, GCC only emits a warning (that is not promoted to an error when building external Library_pdfium) about "register", but at least recent trunk Clang does emit an error by default. (Clang used to have a bug by which it failed to emit any warning/error for uses of "register" on function parameters, but that got recently fixed with <http://llvm.org/viewvc/llvm-project?view=revision&revision=317140> "Fix missing -Wregister warning when 'register' is applied to a function parameter", causing an --enable-werror build failure now when building in C++17 mode with <https://gerrit.libreoffice.org/#/c/43851/> "Build as C++17 when GCC/Clang supports it" locally included.) So instead of trying to further demote any warnings/errors about those uses of "register", just patch them away for good. Change-Id: I7c8757e654d87be710eaaafa871300656d9ee8ff 2017-10-10use gbuild way to update config.*, continuedDavid Tardon Change-Id: I9abf1742c213f47c576ffbb7dafd33087f7037e5 Reviewed-on: https://gerrit.libreoffice.org/43307 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>