summaryrefslogtreecommitdiff
path: root/setup_native
AgeCommit message (Collapse)AuthorFilesLines
2021-03-17tdf#134607 use kMDItemFSName instead of _kMDItemDisplayNameWithExtensionsChristian Lohmaier1-2/+2
apparently the latter is not available on older versions of macOS. https://developer.apple.com/documentation/coreservices/kmditemfsname lists it as in version 10.4 and not flagged as deprecated, so keeping fingers crossed that it is not affected by user-settings or similar… Change-Id: I208d22f2abd628e7d95babc23ddb145a88bcf5cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112385 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit daa162c20f4c7d61edc217ed44cb2854652a63ec) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112528 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-02-08tdf#134607 mac-langpacks: always query for full name with extensionChristian Lohmaier1-2/+2
kMDItemDisplayName has different values depending on the setting whether to show extensions for all filetypes in Finder, breaking the detection/validation of the installation target in case the user doesn't use the default setting. Change-Id: Ic9605abaaa1f070f1f5ec9940190fd1dd2555bdf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110479 Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit dbaf1d75601cb911d1c17e1e63d2c7047f2cf9e1) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110442 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110532
2021-02-08Revert "tdf#134607 workaround – mac langpack: don't verify target location"Xisco Fauli1-7/+6
This reverts commit d6667aec86718cc4b843a69658fcc83203d66734. Change-Id: I7632a8814814a2649cf9685f36a6146abe61a579 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110531 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-09-07tdf#134607 workaround – mac langpack: don't verify target locationChristian Lohmaier1-6/+7
for some reason the commands used don't work for some users Change-Id: Iecd5ffdfcb5c7d8cd5c4202fed0906ebf1ef68f9
2020-07-13tdf#134748: handle Kazakh language in langid_to_stringMike Kaganski1-0/+1
Change-Id: I8829597b7e90ea52dc4a4bdd88cd07730a0c4f12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98600 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit c57865b79654ddd19caad12a892701ca50745800) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98466 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2020-07-02Add Turkish (tr) dictionaryMuhammet Kara2-0/+16
Change-Id: Ibc1e7505e6a7492f4d0714c848a6d1eebcdf4a0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97670 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2020-06-16macOS fix langpack installer with manually selected .app directoryChristian Lohmaier1-3/+4
For cases when there are multiple matching apps where the Languagepack might be installed to, the "make sure to launch LO once before installing the langpack" mechanism can fail. Even if it is the call "tell application <selection> to activate" that fails, the error handler assumes that the untar operation didn't work and suggests to retry with admin privileges, modifying the .app bundle before having it started once (AKA verified by gatekeeper), breaking the app. Passing the full path to the application object should fix that. Change-Id: I47d61ad68e225fbdba191702ba85598164602e81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96449 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit 20c17b0ffb89102d086f80303887a8594f0c3c8c) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96425
2020-06-16tdf#133511 adjust langpack script for removal of CFBundleGetInfoStringChristian Lohmaier1-1/+1
3a028418190790c3bbaf6e505ff55b7bb8c0b474 removed the string from Info.plist, but the languagepack install script tried to use that to make sure whatever the user selects/is found is from the dame type (dev vs release and codeline/version). Instead of doing multiple greps/multiline ones (there are multiple version strings in that file, only one being from LO itself…) use mdls instead to pick the interesting properties to build a "PRODUCTNAME FULLVERSION" string again we can match against. --raw switch is nul separated, so add additional xargs -0 in there instead of trying to match a nul with grep (without --raw it is a nice human readable multiline string) Change-Id: I049a8425709a0c41b61aa09452490b481d39e4d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96439 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit 7708b3f2d62f3defae261cd2d3621ae3b324d9d1) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96419
2020-06-16mac langpack script: simplify mdfind call to not use wildcard matchChristian Lohmaier1-1/+1
I think this is leftover from very early development stages when it didn't have placeholders, but literal OpenOffice or similar at the time. Not matching for wildcard but for full LibreOffice/LibreOfficeDev string makes removing the languagepacks from the match superfluous It was wrong anyway, since kMDItemDisplayName has the name without the .app extension (you'd have to use _kMDItemDisplayNameWithExtensions for that) Change-Id: I37b1ed2d23ea18fd81a8844f35c9cb0d5dc34211 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96441 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit 9da104538dd92861b2b9e4e95ccbafe12632fe83) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96423
2020-05-06Resolves tdf#132701 - macOS installer image must be 72dpiHeiko Tietze1-0/+0
See also 12b389e838743dec662c70c4772553a96ad4f9ac Change-Id: Ib46cd37e29beac4c18b2f9ce5a74b01f6c357cbe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93500 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2020-05-05Some improvements to About box and brandingHeiko Tietze1-0/+0
* Label left-aligned (tdf#132322) * Long build string cut at 25 chars * Extra text such as Tinderbox info wraps now at Misc * UI-Language shortened to just UI * More padding between about image and text * Splash screen uses Vegur font * Splash with small border * Non-TDF logos have a "Community Edition" text Change-Id: I1ec31e22052e365f28fe91de3e083252975911c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93444 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2020-04-30Resolves tdf#130778 - Branding for 7.0Heiko Tietze1-0/+0
Remaining installer images added TDF tagline removed White background on all splash screens Change-Id: Iafde896fd3ed58957ec16ba43565c56e85db925c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93199 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2020-04-20Translate German variable namesJohnny_M1-2/+2
Ende -> End Change-Id: I2d63ddfeb1fa59ed1b0e3bbf2d39d5221cd5425f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92026 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-02-03Set INSTALLLOCATION in one single placeMike Kaganski1-36/+42
It used to be set both in AppSearch action (using RegLocator table), and in MigrateInstallPath custom action. This would overwrite value of INSTALLLOCATION taken from user, and read on the previous step, with values taken on the next step. Only migrating the install location in one single place - in custom action MigrateInstallPath - makes the process controllable. Also it allows to easily see all the various places in registry we read. Change-Id: Ib7e04c26e71ba92c6a62a0511971bfb3bdb7db72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87867 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-02-03tdf#130329: detect previous version's install locationMike Kaganski1-24/+46
Since component ids change across major versions, install location isn't kept automatically for major upgrades. Use OLDPRODUCTS property set during FindRelatedProducts action (see Upgrade table created by solenv/bin/modules/installer/windows/upgrade.pm). Read InstallLocation in existing MigrateInstallPath custom action under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\GUID, where GUID is the value of OLDPRODUCTS. This only reads registry hive for the current installer architecture (32/64 bit), so that the other architecture installation path is not taken into account when old version is of different architecture, to avoid installing into wrong directory when e.g. upgrading from 32-bit to 64-bit, so 64-bit program is not installed to Program Files (x86). Change-Id: Ib9fa004818908a5706c5af040f1a5a36c03d2f36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87844 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-01-10Improve logging of feature statesMike Kaganski1-0/+9
Change-Id: I8b304bbefe861abd7503204f0ae8efb0aea203ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86528 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-01-09-Werror,-Wwritable-strings (clang-cl)Stephan Bergmann1-2/+3
Change-Id: I67287498db35c60f224b095b00e6c058f53c10cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86471 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-09Register spsupp*.dll during installationMike Kaganski4-0/+355
This registers SharePoint integration libraries using regsvr.exe. Both 32-bit and 64-bit libraries are registered; registration of LOSPSupport.OpenDocuments is unconditional. This introduces a new hidden MSI feature, which is disabled for installation: gm_SharePointSupport_SubstMSO. When installed, it registers SharePoint.OpenDocuments class in registry, thus overriding registration of this component by MS Office, allowing LibreOffice to serve as MS Office replacement working in IE with SharePoint. To install the feature, either a transform is needed setting the feature's level <= 100, or a command line: msiexec path-to-msi ADDLOCAL=gm_SharePointSupport_SubstMSO Change-Id: I5517bbb68dcc6db8bcb2bbc2368394ee4a62d741 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86452 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-01-02Bump copyright year to 2020Adolfo Jayme Barrientos7-85/+85
Change-Id: I6fb736591f32907c8977fbac8fbf1dcbaef1bb97 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86092 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2019-11-26loplugin:consttobool (clang-cl)Stephan Bergmann3-16/+16
Change-Id: I81fea38cd737a8be74e6ece333ca37cc434a1c33 Reviewed-on: https://gerrit.libreoffice.org/83765 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-19loplugin:fakebool (clang-cl)Stephan Bergmann5-22/+22
...plus follow-up loplugin:implicitboolconversion and loplugin:redundantcast Change-Id: I9fc9c5cb46fbb50da87ff80af64cb0dfda3e5f90 Reviewed-on: https://gerrit.libreoffice.org/83207 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-11simplify "a = a +" to "a +="Noel Grandin1-1/+1
mostly so that my stringadd loplugin can point out places to improve Change-Id: I9920ee1c99cdb6b811ba67ff9d8e32aa261884b5 Reviewed-on: https://gerrit.libreoffice.org/80618 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-06Fixing "...."Andrea Gelmini1-2/+2
Change-Id: I3424e17cfdfb563fdc5882942031deafae8689fe Reviewed-on: https://gerrit.libreoffice.org/78678 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-07-29setup_native: document more obscure epmfile.pm inputMichael Stahl1-0/+5
Change-Id: I26ca5b61acef2474980f5e916e10bca3a18ceea3 Reviewed-on: https://gerrit.libreoffice.org/76557 Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> Tested-by: Michael Stahl <Michael.Stahl@cib.de>
2019-07-10fix HRESULT_FROM_WIN32 can not be placed inside switch for SDK8.1nd1011-2/+10
For Windows SDK 8.1 HRESULT_FROM_WIN32 is defined as an inline function without the constexpr, which is required for case statement inside a switch. Change-Id: Ibb195ef900926d87ff04f82a6d73112b8858f633 Reviewed-on: https://gerrit.libreoffice.org/75111 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2019-05-07tdf#119044 setup_native: let -core depend on -ooofontsMichael Stahl1-6/+7
Things break without OpenSymbol font. On the other hand, if you install just the fonts, but not anything else, you can happily use the fonts in other applications. So just invert the dependency. Change-Id: I4c2dbff59699365cba67d3b1c6ade5ec7c2462bf Reviewed-on: https://gerrit.libreoffice.org/71898 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-04-22tdf#124794: Wait for WU service stopped before launching wusa.exeMike Kaganski1-40/+96
It seems that wusa.exe would fail with error code 0x80080005 if launched too soon after WU service was sent a stop control (which was added in tdf#123832). Change-Id: I470a8a8e933e8a0cd6208c095ed63c1761b3b434 Reviewed-on: https://gerrit.libreoffice.org/71045 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-04-05Replace legacy dynamically-loaded functions with statically linked onesMike Kaganski1-10/+7
We don't need the dynamic load complexity for these now with baseline Windows version being Windows 7 SP1. Stuff used only for compatibility with older versions was dumped. Change-Id: I810f271796cfd875cfa18a3081c9ad444fe57b3e Reviewed-on: https://gerrit.libreoffice.org/70321 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-04-04Drop UNICODE/_UNICODE definesMike Kaganski3-6/+0
The code is using expicit (mostly W) Windows API, and is independent from the macro. Removing it here allows to catch places where some UNICODE-dependent macro is used unintentionally. Change-Id: I5dff40aecfc3c3dc7fc4cf7271a995a675943a45 Reviewed-on: https://gerrit.libreoffice.org/70237 Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-03-31tdf#120703 PVS: Silence V575 warningsMike Kaganski3-0/+7
V575 The potential null pointer is passed into 'foo' function Add asserts to those cases that are related to OOM cases. There's nothing to be done if the assertions fail anyway. Change-Id: I92ac95d44f512aa1948b1552b0e1f6da695a9f92 Reviewed-on: https://gerrit.libreoffice.org/70008 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-03-22tdf#123832: Try to prevent/control hung wusa.exe while installing UCRTMike Kaganski1-25/+76
Reportedly under some circumstances execution of wusa.exe may hang for very long time (available logs show more than 90 min). LO MSI installer waits for wusa.exe indefinitely in its deferred inst_msu custom action; during this wait, one can't abort the installation. There is an evidence [1] that stopping WU service prior to wusa launch might prevent this hang. The patch does two things: 1. It stops running WU service prior to wusa launch. 2. It adds a check for user input by executing MsiProcessMessage twice a second, and checking its return value, to allow early return in case user cancels the installation. This is a blind shot, since I cannot reproduce the problem myself. [1] https://superuser.com/questions/1044528/ Change-Id: I8bf4ce52b3e9d98a4f90af3abcc49ac63b6a0e40 Reviewed-on: https://gerrit.libreoffice.org/69487 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-02-26loplugin:indentation (clang-cl)Stephan Bergmann1-6/+6
Change-Id: I94689e4eed290b4505d2caba2d9802ef7fb6cffd Reviewed-on: https://gerrit.libreoffice.org/68378 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-30loplugin:redundantinline (clang-cl)Stephan Bergmann6-7/+7
Change-Id: Ib6320ddc049e93cca4c5931ad28d1873d34bd8b4 Reviewed-on: https://gerrit.libreoffice.org/67137 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-16Small corrections to stringsMatthias Seidel1-3/+3
(cherry picked from commit ecb016e11bffa4ce6d9793c96e65f9252c13e356) Change-Id: I963c554234d335dff758e94822259cf44254de9b Reviewed-on: https://gerrit.libreoffice.org/66435 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-01-01Bump copyright year to 2019Adolfo Jayme Barrientos7-85/+85
Change-Id: I0d49ec7db57a0f7d18489dad61e86cbfdf4418cd
2018-12-24tdf#122302: Set status message when installing KB2999226Mike Kaganski1-15/+33
Change-Id: I414959f0f278792c5cac0c58746faa6b7773e494 Reviewed-on: https://gerrit.libreoffice.org/65593 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-16tdf#121987 follow-up: never fail MSU install; warn instead.Mike Kaganski1-58/+56
This replaces commit 53058090beede6a399e2f408f62c28a2921ff8ab. Now not only failure to start WU service, but also other errors during MSU installation won't break installation. E.g., running WU service as Guest does not prevent the service from starting; but installing updates fail, which makes previous solution incomplete. Instead, show a warning in those rare cases when an error happens, and continue. It will allow users to see the reason if they see "api-ms-win-*.dll missing" message later after installation. Of course, some small percentage of these warnings will be false, e.g. those on Windows 10. But those false messages must be really small minority, because only when (1) the installation fails (2) on a system with the component already present, such a message would be false. And it will not prevent the installation. This will not block unattended installations, since in those cases, MsiProcessMessage() will do nothing. Change-Id: I3a9e681e9d6701d092bd5c18bb4b68b4f77170f3 Reviewed-on: https://gerrit.libreoffice.org/64874 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-09tdf#121987: Don't fail installation if failed to enable WU serviceMike Kaganski1-19/+47
Since commit 1882827320ed760de82211cf690b686f8d34ff74, an attempt to install UCRT will be performed regardless there is an evidence that it's present on the system, to workaround some cases where the existing UCRT is broken (tdf#115405, tdf#119910). But that made other errors to emerge: on systems where users disable WU service using some exotic ways, installer is unable to enable the service, and fails. [1][2] Examples of such hard-disables are using `sc delete` [3] and associating WU service with a guest account. Many such cases are reported for Windows 10, where installation of the UCRT is not required. So the solution (imperfect, but possibly the best possible here) is to allow installer to continue in case of failure enabling the service. This will automatically eliminate all problems related to Win10; and also for cases where users are advanced enough (the majority of such hard-disable cases should be those), it might be enough to add a relevant FAQ entry. [1] https://ask.libreoffice.org/en/question/172227/cannot-install-631/ [2] https://ask.libreoffice.org/en/question/175571/installation-failed-unknown-error-win10x64/ [3] https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/sc-delete Change-Id: Ie85016eb6f0667f39412a3089fe1b1855cb1fc73 Reviewed-on: https://gerrit.libreoffice.org/64825 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-11-29Rename Mac OS X to official name macOS in comments and documentationBartosz Kosiorek1-1/+1
Change-Id: I651b7f202fa52ff5f5357a11aa72c43eb7dc7f95 Reviewed-on: https://gerrit.libreoffice.org/64102 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2018-10-27tdf#120703 PVS: V530 The return value of function is required to be utilizedMike Kaganski1-1/+1
Change-Id: Ifc170a45e25b3fd5b7f561cc50afb6452bb359bd Reviewed-on: https://gerrit.libreoffice.org/62420 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-09-30Correcting description: Gnome -> GNOMEMatthias Seidel2-2/+2
(cherry picked from commit 72b2299f3ec474a09e00f4966abc8c37bb972ec1) Change-Id: I8bc06a07974f98707df39ff39d9e1a215cba9c52 Reviewed-on: https://gerrit.libreoffice.org/61156 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-09-28tdf#120099 Reintroduce .def filesStephan Bergmann18-0/+51
...that had been removed with 28b4f4aeaf160c7721dfecf5bd2445d7dbc6f01c "Get rid of Windows .def files in setup_native, use __declspec(dllexport)". Looks like for 32-bit builds, the .def file EXPORTS are still needed to avoid __stdcall's _...@NN symbol decoration (and for 64-bit builds __stdcall is effectively ignored, so the removed .def files didn't make a difference there). This is only a partial revert of 28b4f4aeaf160c7721dfecf5bd2445d7dbc6f01c, the addition of __declspec(dllexport) for the benefit of loplguin:external should still be fine. Change-Id: I76a1a3f4671824367bab495afeba291c0340108d Reviewed-on: https://gerrit.libreoffice.org/61047 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-09-24loplugin:external (clang-cl)Stephan Bergmann6-17/+17
Including: * expanding STDAPI to its definition (as per <https://msdn.microsoft.com/library/ms686631(vs.85).aspx> "STDAPI"), to add __declspec(dllexport) into its middle, in extensions/source/activex/so_activex.cxx; as discussed in the comments at <https://gerrit.libreoffice.org/#/c/60691/> "Get rid of Windows .def files in setup_native, use __declspec(dllexport)", having a function both listed in a .def file EXPORTS and marking it dllexport is OK, and the latter helps the heuristics of loplugin:external; however, the relevant functions in extensions/source/activex/so_activex.cxx probably don't even need to be exported in the first place? * follow-up loplugin:salcall in sal/osl/w32/file-impl.hxx Change-Id: Ida6e17eba19cfa3d7e5c72dda57409005c0a0191 Reviewed-on: https://gerrit.libreoffice.org/60938 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-09-18Get rid of Windows .def files in setup_native, use __declspec(dllexport)Stephan Bergmann34-75/+24
For one, replacing the dated .def files with equivalent functionality should be a good move all by itself. And for another, it paves the way for using loplugin:external with clang-cl on Windows, which uses the heuristic of not warning about functions that are explicitly marked as __declspec(dllexport). Change-Id: I6efd50a8c5ce2a166ca0dd4e5f472118f3f9a071 Reviewed-on: https://gerrit.libreoffice.org/60691 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-09-01package Indonesian (id) dictionaries into installsetChristian Lohmaier2-0/+16
Change-Id: I78b8c745b9d6e4a23fa13622188c5bd1776b0ac6 Reviewed-on: https://gerrit.libreoffice.org/59882 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2018-08-27Remove Extensions_MySQLConnector junkStephan Bergmann1-15/+0
...left over from 26b40fcfc67480e75bd9959b0c5cb9db10fdf6a1 "Moving mysqlc into connectivity as a library". (Apparently, for one, a module's Files that don't exist are ignored, so 8ecf5e1815b5459bc0bbcdfb398d3bd53b0c2861 "Build fix, make install: mysql-connector-ooo extension is gone" removing gid_File_Oxt_MySQLConnector but not gid_Module_Optional_Extensions_MySQLConnector referencing it didn't cause trouble; and for another, an empty module is ignored, so there were no extension-mysql-connector packages generated any more---but better clean up the junk anyway.) Change-Id: If598a968dfbbe9b5f16d735e8011e192cbd4178b Reviewed-on: https://gerrit.libreoffice.org/59669 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-07-19Fix typosAndrea Gelmini1-2/+2
Change-Id: Id31aa22a98f7520a37e624cbb1dc4d949246c0fb Reviewed-on: https://gerrit.libreoffice.org/57622 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-05-01loplugin:nullptr (clang-cl)Stephan Bergmann1-2/+2
Change-Id: I302cb394b1883932d4cb7b160a4a74185dbff04b
2018-04-25Install UCRT from MSUs, not using nested VC Redist installMike Kaganski4-0/+561
Using nested install is bad because (1) MS advises against it (though it most possibly doesn't relate to our specific case, when we install the vc redist exe package in UI part, so actually only a single MSI session is active at any time); (2) because it adds some extra interactions (user sees something "unrelated" being installed, which raises concerns; additional admin authentication required); and (3) because it runs in InstallUISequence, thus only installing the UCRT when doing interactive installation (unattended installs, including GPO, need to install UCRT separately). This patch aims to incorporate the original UCRT MSU (Windows Update) packages (https://support.microsoft.com/en-us/help/2999226) available as a zip archive from https://www.microsoft.com/en-us/download/details.aspx?id=48234 - the same as used in VC redists for VS 2015 and 2017. This obsoletes the separate installation of the redist; since we also have the redist as merge module in our MSI, that is enough (and removes redundancy). The MSUs are installed using wusa.exe in a custom action (deferred, non-impersonating). As a small bonus, embedding MSUs instead of redist EXE allows us to shrink the size of installer a little (~10 MB). As deferred custom actions cannot access current installer database, we workaround this by using initial immediate impersonating action to extract the binaries into a temporary location. To ensure that the file gets removed upon completion (both successful and failed), we use an additional cleanup action. Commit 61b1d631331551b43bc7d619be33bfbfeff7cad6 is effectively reverted. Change-Id: I1529356fdcc67ff24b232c01ddf8bb3a31bb00bd Reviewed-on: https://gerrit.libreoffice.org/52923 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-04-13I guess it's time to remove some Win9x codeMike Kaganski2-47/+12
Change-Id: I921207fb73b2dc1e0f55836fa87c3338ff4fe1a9 Reviewed-on: https://gerrit.libreoffice.org/52807 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-28 05:57:35 +0000