summaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2018-01-16Fix typosAndrea Gelmini
Change-Id: I078626eaa3155cc429320cc8c1532003b382b22a Reviewed-on: https://gerrit.libreoffice.org/47855 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-01-07Find JDK 9 on WindowsStephan Bergmann
Change-Id: I8854d0e7fb23602e5ca20309fc79890b4f31a70e Reviewed-on: https://gerrit.libreoffice.org/47479 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-01-04iOS disable gpgmejan Iversen
Disable gpgme called for passing parameters to configure, when called internally (to generate config_build etc). Update the distro-conf, with info on the different supported models Change-Id: I884c8638bf7b1c9fbc8ea4bdaa4dfca019857f45
2017-12-30iOS, bump version to 11.2jan Iversen
Change-Id: Ia24e872f138a78d3d585150e3cde78858de60b77
2017-12-30Support for tcmalloc and jemalloc is long deadStephan Bergmann
When it was originally added to --with-alloc (tcmalloc: f63ffaf3667e218be3538e84e6becc18d5de4334, 54efc5ed83890f0a1166ece3b1e4942bb7922ff7, 0abd71b44144220d2aeec58601929fd0cd1914d6 708b6d4246de915ac960c7b90ee8bb2d966c7d17 "INTEGRATION: CWS configure14: #i59160# allow usage of tcmalloc and system-malloc"; jemalloc: 826a90d68a4dc458585c6d2e647bec17971e9193 "configure25: #i111045# jemalloc"), the old build system's solenv/inc/unxlng*.mk added corresponding -l switches to linker command lines, but it appears that was never carried over into the new build system. And even if the AC_CHECL_LIB calls in configure.ac prior to e612f026de6ca1153c57fb10f0fa75725425a301 "Ensure AC_CHECK_LIB/AC_SEARCH_LIBS do not poison LIBS" would have extended LIBS with the correpsonding -l switches, there appears to be no mechanism in the new build system that would have depended on letting that have any effect on which alloc lib to link against. So the only remaining effect of --with-alloc={tcmalloc,jemalloc} is to set FORCE_SYSALLOC in Library_sal.mk, same as --with-alloc=system does. So whoever still uses the former configure switches should just switch to the latter. (Also adapt the documentation of --with-alloc to reality, "internal" instead of "oo".) Change-Id: Iac0e302c5f9602daf5f8452a0fc1887dc55ee27b Reviewed-on: https://gerrit.libreoffice.org/47178 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-22request installation of langpack via packagekitCaolán McNamara
if ui is set to track the locale automatically and the current locale has no match in installed resources but has a match in the list of languages that libreoffice was compiled to contain so e.g. de_AT locale shouldn't trigger the installation of anything if langpack-de is already installed and yue_HK shouldn't trigger install of anything cause that not supported (at time of writing) for libreoffice put Fedora/RHEL/Ubuntu naming schemes in here. I moved the lang code from svl to svtools so I could use the restart dialog to prompt to restart after the langpack is installed, but packagekit's blocking mode seems to be no longer blocking and control returns immediately which is a change since the last time I played with this stuff, so drop the restart thing for now. The lack of a blocking modal also makes the "run this on idle when there's a toplevel window up and running" a bit futile, but lets keep that for now anyway. caolanm->rene: I know you'd disable this anyway, so Debian is left out, there's also config key Office/Common/PackageKit/EnableLangpackInstallation to disable this too. Change-Id: Ice731be539850338ccdd8af87839e0b4d83f01e7 Reviewed-on: https://gerrit.libreoffice.org/46856 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-12-22gtk3 is no longer experimentalMarkus Mohrhard
Change-Id: I00b36e7109b1e4c286248aff75150ba3ef2d44b1 Reviewed-on: https://gerrit.libreoffice.org/46940 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Jenkins <ci@libreoffice.org>
2017-12-20Fix typosAndrea Gelmini
Change-Id: I361b5283b092171eaaaf46fa3c1fb13faa53bd7a Reviewed-on: https://gerrit.libreoffice.org/46821 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2017-12-19Bump --enable-compiler-plugins to Clang 3.8.0Stephan Bergmann
<https://lists.freedesktop.org/archives/libreoffice/2017-December/079107.html> "Clang baseline bump" Change-Id: I18fca8794ea34118fc6308458064d0c28cf5caf7 Reviewed-on: https://gerrit.libreoffice.org/46557 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-19Remove unnecessary -Wunknown-pragmasStephan Bergmann
...which was added with 92dfa82d2d25f2acdee0a538bf15f1fac36c0ecf "adjust for upstreaming of warn_unused attribute" but appears to be unnecessary cargo-copy from bdb87236dcbc1187b15e1a457e130ff997b0949b "Fix pragma GCC diagnostic checks". Both old GCC (e.g., 4.8.5) and Clang (e.g., 3.4.2) emit a -Wattributes warning/error here by default. Change-Id: I2fd81ac411000c4b851a77de432bf14eb1bc0d61 Reviewed-on: https://gerrit.libreoffice.org/46796 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-19Remove obsolete Clang <= 3.1 checksStephan Bergmann
...after fa7b7f73938e837af2765f8a03f07e404046877b "Document that Clang 3.4.2 is known to be too old" Change-Id: Ia9fc056b58c7674c8aa0e0bf6c079ecd56d06629 Reviewed-on: https://gerrit.libreoffice.org/46771 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-19The Clang __float128 hack is already needed earlierStephan Bergmann
...when determining the -std= value, as that also includes <vector>. (And also note that the hack doesn't help with later libstdc++'s <algorithm>, anyway.) Change-Id: Id49b6be71e536369a9268060cb1e8ef3fbaab481 Reviewed-on: https://gerrit.libreoffice.org/46770 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-18tdf#108580: integrate vc_redist.exe into MSIMike Kaganski
... in InstallUISequense. Use --with-vcredist-dir to point to a directory with vc_redist.x64.exe and/or vc_redist.x86.exe. Use --without-vcredist-dir (or --with-vcredist-dir=no) if you don't want to ship it as part of installer and want to silence the configure warning. VCRedist 2015 version 14.0.24215.1 is available at https://www.microsoft.com/en-us/download/details.aspx?id=53840 Since VisualStudio 2015, VC redist merge module that we used before started to work differently: it installs the UCRT only on WinXP, but not on later OSes (Vista to 8.1) which may lack the UCRT (Win10 has it out of the box). The merge module only installs VCRuntime on those systems, which still leaves us with "api-ms-*.dll is missing" problem. (https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ gives more information on VCRedist refactoring background.) Since commit 71d9a61302e65fe091cf70c13fa72b3df09b7e3a, we use a workaround described at the page mentioned above as "App-local deployment of the Universal CRT". We just copy all UCRT DLLs to LibreOffice/program. This has a drawback though, that our UCRT is not updated by Windows Update, so users would rely on LibreOffice updates in case of some vulnerabilities in UCRT (and they could even not realize they have that problem). MS recommends to install UCRT using EXEs they provide from their site. The EXEs install both VCRuntimes and UCRTs, along with required patches, for all Windows versions (Windows XP through Windows 10, where they only install VCRuntimes); the installed libraries are managed by system's update mechanism. But those EXEs cannot be used in MSI custom actions inside InstallExecuteSequence, because they use MSI themselves. So this patch integrates the vc_redist.xXX.exe into MSI binary table, and uses custom action to run the EXE after ExecuteAction in InstallUISequence. This will show the user a VCRedist install window after the main LibreOffice installation finishes; no user interaction is required (except for one additional UAC request), and errors are ignored. Since this installation takes care of both VCRuntime and UCRT, we can ultimately drop both the app-local workaround, and vcredist merge module (so VCRuntime would also be updated by system). The former is done here: this reverts commit 71d9a61302e65fe091cf70c13fa72b3df09b7e3a. This approach has its drawback: if one wants to use unattended installation (without UI; one example is deployment using ActiveDirectory GPO), then InstallUISequence is not run, and so VCRedist isn't installed. In this case, one should install VCRedist separately. Supposedly this should not be huge problem, because this is the case for many existing applications that need separate VCRedist deployment in these scenarios, and unattended installation is advanced stuff that requires prepared user. A notice would be required in release notes and FAQ, though. Change-Id: Ia6a16be60af8a08f41ea7c3dbd457d8f89006006 Reviewed-on: https://gerrit.libreoffice.org/46356 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-12-15Enable C++17 for clang-cl, tooStephan Bergmann
Similar to libc++ in C++17 mode, some types like std::auto_ptr are indeed removed in C++17 mode by default, and need _HAS_AUTO_PTR_ETC=1 to be enabled (see <https://blogs.msdn.microsoft.com/vcblog/2017/12/08/c17-feature-removals- and-deprecations/>). Unlike libc++, also std::binary_function and std::unary_function are removed (and need the same _HAS_AUTO_PTR_ETC=1 to enable). So either set that flag to make external code build, or use patches (for external/mdds) to make externals' files included in LO proper still work there. Change-Id: I886cc0de8196255334ee03ec48cb4bc54d460afd Reviewed-on: https://gerrit.libreoffice.org/46514 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14Upgrade to ICU 60.2Eike Rathke
Change-Id: I1a5653669f5d15b5cdca0967c82263f0b7d17b3c Reviewed-on: https://gerrit.libreoffice.org/46470 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins <ci@libreoffice.org>
2017-12-14external: upload libepubgen-0.1.0Miklos Vajna
The only change is that version support is now available unconditionally, otherwise most code changes were bundled already in the form of patches. Change-Id: I0e456d85c9d84002cabcd77b31b02c9a7ad16ac5 Reviewed-on: https://gerrit.libreoffice.org/46386 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-12-12system gpgmepp can't be used with dbgutilDavid Tardon
Change-Id: Ib308a6328ce0caabf47d0ba28c3b1a52c89014a8
2017-12-09gpg4libre: check if we can really verify OpenPGP signaturesThorsten Behrens
And disable unit tests otherwise Change-Id: I32e1d8d2f8b0013d9cb43b78a55d23a1a29a8e8d Reviewed-on: https://gerrit.libreoffice.org/46057 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-12-08New --enable-compiler-plugins=debug modeStephan Bergmann
...to enable debug-only code in the plugins. Some situations in the plugin code should never happen, yet must not by default report errors or trigger assertions, as some newly written LO code could trigger them nevertheless (in which case the plugin code will likely need to be adapted, to cater for these presumed-impossible situations). Such code can now be included in the plugins behind an if(isDebugMode()) guard, and can explicitly be enabled with --enable-compiler-plugins=debug. I deliberately made this a runtime rather than a compile time option (using some #ifdef guards in the plugin code, say), as it IMO keeps the code more readable, and also allows overridding COMPILER_PLUGINS_DEBUG=... on the make command line. Change-Id: Iea4f0c2783ad968a0de097fa710b3be1a248de73 Reviewed-on: https://gerrit.libreoffice.org/46096 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-08gpg4libre: rename GPGME_HAVE_GPGME to HAVE_FEATURE_GPGMEThorsten Behrens
Change-Id: I6f085b67c3477f427bd1efd96db93cbb89e20647 Reviewed-on: https://gerrit.libreoffice.org/46050 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-12-07allow to build online help tooDavid Tardon
Change-Id: I9b26f952dc681893b25712451535f4b539fd615d
2017-12-07allow to build only HTML helpDavid Tardon
Change-Id: I4debf079be228e5ce5fae5f1a153f78800407a59
2017-12-06Work around latest Boost 1.65.1 still using deprecated std::auto_ptrStephan Bergmann
...in various places, which is gone by default at least from recent libc++ in C++17 mode. So bring it back there for now, until Boost is fixed. Change-Id: I0b3128d114ab2b5693a84bdc7d2b9b9b9b5c3c76 Reviewed-on: https://gerrit.libreoffice.org/45910 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-06Remove CXXFLAGS_CXX11 from Clang plugin compilationStephan Bergmann
CXXFLAGS_CXX11 is for the compiler used to compile LO proper. The plugin needs to be compiled in a way compatible with compiling Clang, and the compiler and any relevant flags can be controlled with COMPILER_PLUGINS_CXX. (And at least on macOS when compiling LO against a locally-built recent Clang trunk, CXXFLAGS_CXX11 will now contain -std=gnu++17, but COMPILER_PLUGINS_CXX can still point at Apple's Xcode clang++, which does not understand -std=gnu++17.) Also, if COMPILER_PLUGINS_CXX is not set, simply default it to g++ instead of trying to construct an acceptable CLANGCXX value from CXX (which would be Clang). (The problem with using Clang without CXXFLAGS_CXX11 is that Clang, unlike GCC, typically defaults to C++03, but building compilerplugins requires C++11 at least. That would cause e.g. the Gerrit/Jenkins linux_clang_dbgutil_64 builds to fail---but which also needs COMPILER_PLUGINS_CXX to be explicitly set to "g++ -std=c++11" as GCC on those machines is still 4.8.5 defaulting to C++03.) Change-Id: Id4ee4e54fa871cb6e621069cd050ae5b31922b34 Reviewed-on: https://gerrit.libreoffice.org/45856 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-06Revert "gpg4libre: add glib2 dependency for Windows"Thorsten Behrens
As it turns out, gpgme works perfectly fine w/o glib (though it really wants it configured out of the box) This reverts commit daee5fc5569c1807f5c8dae502d305eb06141e8b. Change-Id: I60002bf3b524696eeae397a26c280a67dcdbfd7a Reviewed-on: https://gerrit.libreoffice.org/45908 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-12-05drop opencl and clew for fuzzingCaolán McNamara
Change-Id: I6b438e32b1be1ee8fbd72d296e3824b8bb473e8e Reviewed-on: https://gerrit.libreoffice.org/45878 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-12-05Disable C++17 when system libcmis headers contain dynamic exception specsStephan Bergmann
Change-Id: I7b94e784a3e145aa7c8a910ee08034d6ff9b2693 Reviewed-on: https://gerrit.libreoffice.org/45869 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-04Fail when building Win64 from cygwin32Thorsten Behrens
The gpgme libs need cross-arch windres support, which cygwin32 lacks. Change-Id: Icbe013cf7983754e8b485dd7368cfc10f8fd0bcb Reviewed-on: https://gerrit.libreoffice.org/45769 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-12-04EPUB export, fixed layout: fix spine namesMiklos Vajna
They are pages, not sections. Change-Id: Ifd72d5ebec1d372a9bd99653d849479a6ffb6bfa Reviewed-on: https://gerrit.libreoffice.org/45690 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-12-04Remove arch-pinning for gpgme on Windows againThorsten Behrens
With e0d94237878d4949573fc9b6d97eea3146cada6d the dependency on gcc is gone, so we should be able to build on all cygwin flavours again for all Windows arch targets. Well almost - we still have windres on cygwin32 only able to produce pe-i386 targets, so let's exclude the case cyg32 and WIN64 for the moment. Change-Id: Ibe7f967585995586985177d4c36cc33d9850d9de Reviewed-on: https://gerrit.libreoffice.org/45422 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-12-03require at least gtk3 3.18.0 to build and run gtk3 bitsCaolán McNamara
Change-Id: I02efb169ba1d0756d2d9c4b77c3c2b58e48c4a82 Reviewed-on: https://gerrit.libreoffice.org/45727 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-12-02require at least gtk3 3.16.0 to build and run gtk3 bitsCaolán McNamara
Change-Id: I38cd6bcd9ed01695be4345add9d7c0a43a921d04 Reviewed-on: https://gerrit.libreoffice.org/45721 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-12-02require at least gtk3 3.14.0 to build gtk3 bitsCaolán McNamara
Change-Id: Ide498b03f21e2c3b8fb47c565079af26ead1d762 Reviewed-on: https://gerrit.libreoffice.org/45712 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-12-02require at least gtk3 3.12.0 to build gtk3 bitsCaolán McNamara
Change-Id: I608fa4075eadd0b3ed038c26aba5d9383a99b314 Reviewed-on: https://gerrit.libreoffice.org/45669 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-12-02require at least gtk3 3.10.0 to build gtk vclplugCaolán McNamara
Change-Id: I4ca34184237d05b999c92648494c306a1f1371cd Reviewed-on: https://gerrit.libreoffice.org/45668 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-11-30Do not check in qt5 checks for Qt4 bugs that were fixedTomáš Chvátal
Change-Id: I4d4725c775e98fe397e43d7b6ae02eb98dc79aa0 Reviewed-on: https://gerrit.libreoffice.org/45507 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-11-29configure: check that graphviz/dot is found, needed by doxygenMichael Stahl
Change-Id: I70937c4c6075ce1814c3be5b8613fb28cd28fc26 Reviewed-on: https://gerrit.libreoffice.org/44408 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-11-28Avoid C++17 mode for Coverity ScanStephan Bergmann
...see mail sub-thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-November/078966.html> "Re: New Defects reported by Coverity Scan for LibreOffice" about cid#1424266 et al; lets see if this makes Coverity happy again... Change-Id: If488b9f61f084f2286b35326917741051ec8d5ce Reviewed-on: https://gerrit.libreoffice.org/45403 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-11-28upload libwps 0.4.8David Tardon
Change-Id: Ib285c227cd935987311be40df3745316943a54e0 Reviewed-on: https://gerrit.libreoffice.org/45331 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2017-11-26Remove dated configure check after LO 6.0 branch-offStephan Bergmann
See c127c19de62201b49b6647ef3ee8b08ae49da852 "Remove HAVE_CXX11_REF_QUALIFIER, always true now". By now, any outdated builders where this would fail should have been identified and taken care of. Change-Id: I5f823b48b40dd6a20991ebb118e077a0e88aacb1 Reviewed-on: https://gerrit.libreoffice.org/38887 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-11-26Build as C++17 when GCC/Clang supports itStephan Bergmann
...and the gperf being used no longer emits "register" in C++ code. Unlike Clang with -Wdynamic-exception-spec ignored, at least GCC 7.2 -std=gnu++17 always makes dynamic exception specs hard errors, which would cause errors both when building StaticLibrary_libcmis and when including libcmis/libcmis.hxx in ucb/source/ucp/cmis/. So patch away all dynamic exception specifications from all external/libcmis include files indirectly included via libcmis/libcmis.hxx, and (to silence the remaining dynamic exception specifications in the innards of external/libcmis, which I did not feel like also patching away) build StaticLibrary_libcmis as C++03 if necessary, and wait for upstream libcmis to eventually be ported to C++17. And external/firebird needs to be built with CXXFLAGS_CXX11 (which amounts to C++17 with this patch) since 9206a08ada00e8762c4a634f242bd566028964bb "Upgrade to ICU 60.1", so the relevant dynamic exception specifications had to be patched away from its innards. Change-Id: I3a0c9ec83c7c1d413559459631970f69ab977f31 Reviewed-on: https://gerrit.libreoffice.org/43851 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-11-25bump product version to 6.1.0.0.alpha0+Christian Lohmaier
Change-Id: I31fcaac33c773752c845628792e0491c8b8f4ccf
2017-11-24add intro-highres.png to list of brandables in configureChristian Lohmaier
Change-Id: I51e8b0739498c5cda9822e5f3879b513fcc47887
2017-11-24fix build with system gpgmeppDavid Tardon
Change-Id: If0c81f5095b61d41b90db2e596bf5905b15ab506 Reviewed-on: https://gerrit.libreoffice.org/45210 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2017-11-24iOS, added IOS_DEPLOYMENT_VERSIONjan Iversen
Change-Id: Ie72c8303011df8a4e0e489ab505e619bd7a40e12
2017-11-23gpg4libre: conditional-compile gpgme codeThorsten Behrens
Change-Id: I1d139a7b6df271d61bedd107c6b3a0535d233606 Reviewed-on: https://gerrit.libreoffice.org/45124 Reviewed-by: Siegmund Gorr <siegmund.gorr@cib.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-11-23Don't warn about the installer unless we are building an installerTor Lillqvist
Change-Id: Iefb40baab9eeaab6923a0f95681466afc6dc6643
2017-11-22gpg4libre: cleanup gpgme & add gbuild lib for gpgmeppThorsten Behrens
This moves the external to gpgmepp, since that's what we _actually_ link against; plus tons of enablement for Windows build, mostly related to linker probs integration. There's still no good way to build a DLL with autotools, so we fall back to gbuild manual make, see also tdf#91480 Change-Id: Ifd8217ef58536612d2389d48e343db133a13fb9c Reviewed-on: https://gerrit.libreoffice.org/44970 Reviewed-by: Siegmund Gorr <siegmund.gorr@cib.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-11-22gpg4libre: build gpgme natively on windowsDavid Ostrovsky
Change-Id: I0b77ba0c1b8f84affa483181e26a26beaf39e878 Reviewed-on: https://gerrit.libreoffice.org/42838 Reviewed-by: Siegmund Gorr <siegmund.gorr@cib.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-11-22gpg4libre: build libassuan natively on windowsDavid Ostrovsky
Change-Id: Id374ebc5ed70a1b4313dc74461524ac2b864b114 Reviewed-on: https://gerrit.libreoffice.org/42745 Reviewed-by: Siegmund Gorr <siegmund.gorr@cib.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
generated by cgit (git 2.34.1) at 2025-01-17 21:43:46 +0000