summaryrefslogtreecommitdiff
path: root/odk
AgeCommit message (Collapse)Author
2021-07-18Fix typosAndrea Gelmini
Change-Id: I0a8ce634944df4af5c9e2000af5f6429b4e40b2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119097 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-07-16Porting C++/Java DocumentLoader example to PythonHossein
* Using UNO for Python * Opening the file in LibreOffice if it is listeing on port 2083 Change-Id: I14b1a38da5d66dd2ee8c859071c148ce08a080d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118142 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Tested-by: Jenkins
2021-07-14Fix typosAndrea Gelmini
Change-Id: I809231e7e6ceaa93c2d0b523de8a4b93b07b449c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118841 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-07-13Ported Draw example from Java to C++ and done some tweaksHossein
* Created Draw.cxx * Used Makefile from DocumentLoader with some changes * Updated examples.html to reflect the addition * Updated odk make files Change-Id: I37426d63854222ef8bedb5f61edb420baec4d28a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118034 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-07-12Cleaning up DocumentLoader C++ SDK exampleHossein
* Removing calls to C functions * Simplifying string usage Change-Id: Ia8ca329d7ad586d98e309809e430006eaac9eaaa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118131 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-07-01Update documentation for uno executableSamuel Mehrbrodt
After -r parameter was removed with 5a1d51139c580dc64578d36dc1b4a31a4e5e0ef8 Change-Id: I1961f35ea375e7fd7426958275de0809c8fc9e2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118087 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2021-06-23Remove unused DOCTYPE from odk/examples xcu fileStephan Bergmann
The declared entities have apparently never been referenced ever since the file's introduction in 9fa09d43d0dc0ec0ac71bad31b85ce7fc302ee90 "INTEGRATION: CWS sdkinspector2". (And at least xmlreader skips and ignores the content of such document type declarations anyway.) Change-Id: I8263200f52bb5f1692090995574619f9c0ec478f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117658 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein
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>
2021-03-24Using .md extension/Markdown syntax for modules READMEHossein
Renaming all README files for all top level modules to README.md, applying no content change at this stage to be able to track history of the files. These files should be edited to use correct Markdown syntax later. Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-03-23Rename LO Windows arm64 ID to aarch64Jan-Marek Glogowski
The Windows platform is called Arm64. But now that the ID for Mac is also going to be renamed from arm64 to aarch64, this get's rid of the arm64 as the UNO identifier and user in gbuild, just like on all other Arm64 platforms. Change-Id: I60a7eafd04b426f17b6e41ad9a09e6405c0d4173 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112973 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-02-01Drop FAR/NEAR from 16-bit WinAPI timesMike Kaganski
Change-Id: Idf71c662138c281333a83cc76a9d75cbf086f362 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110236 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-05tdf#96505 : Get rid of cargo cult long integer literalsumutbayramoglu
Change-Id: I7b269fb5bafceba071ebe649a696ef61301c4018 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107366 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-01-03Bump copyright year to 2021Adolfo Jayme Barrientos
Change-Id: I3159bfc21a35fc80aef57c7d809d8ea8c62a732e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108566 Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2020-12-05Silence cid#1470402 FB.DM_DEFAULT_ENCODINGStephan Bergmann
...where the default encoding should be the appropriate one for reading the Runtime.exec output Change-Id: Ib64bfcbcca985f2de506f8628b506e6dc7bfc035 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107255 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-03Replace unowinreg.dll with execution of `reg QUERY`Stephan Bergmann
The SDK's <https://wiki.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/ Transparent_Use_of_Office_UNO_Components> on all platforms included the Windows- specific unowinreg.dll in generated jars (so that those jars, when distributed to a Windows environment, would find a LO installation by inspecting the Windows registry). That unowinreg.dll was originally built as a 32-bit DLL (though when building a 64-bit Windows LO, it happened to be built as a 64-bit DLL). For non-Windows LO builds, it could either be built locally with a MinGW toolchain (--enable-build-unowinreg) or downloaded from dev-www.libreoffice.org. However, that had various issues: For one, unowinreg.dll was not necessarily available in a distributed jar as a 64-bit DLL for use with a 64-bit JRE on Windows. (Theoretically, running such a jar with a 32-bit JRE to access a 64-bit LO installation's URE jars could have worked. But practically, those URE jars in turn require native DLLs, which would then not have been available as 32-bit DLLs for use in the 32-bit JRE.) For another, at least the unowinreg.dll resulting from --enable-build-unowinreg on Fedora 33 would have had a dependency on libgcc_s_dw2-1.dll that would generally not have been available in a target Windows environment. There appears to be no pure Java way to read the Windows registry, but instead of using a native code DLL for that, it appears to work just as well to call out to reg.exe and parse its output. This removes the --enable-build-unowinreg and --with-mingw-cross-compiler configuration options. (The sole use of the MinGW toolchain in LO was for building unowinreg.dll.) Change-Id: I3283ea38c884d3221a205e5ab6ec99a2691ef474 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107140 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-11-21tdf#123936 Formatting files in module odk with clang-formatPhilipp Hofer
Change-Id: I427263ee98206c00cd2b3392fc9f2f55ad1ded5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105692 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2020-10-04odk: fix Windows Arm64 buildJan-Marek Glogowski
I didn't change odk/util/check.pl to handle the currently missing climaker. I hope this problem will eventually be fixed before anybody really considers developing with LO ODK on Arm64... Change-Id: Icc070bde77e73362646d62401410277a85d3d697 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103879 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-27Restrict odk/examples to non-parallel makeStephan Bergmann
At least odk/examples/DevelopersGuide/Spreadsheet/Makefile contains two independent invocations of unopkg (i.e., $(DEPLOYTOOL)) and CustomTarget_odk/build-examples_java had once failed for me with > "~/lo/core/instdir/program/unopkg" add -f "~/lo/core/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/bin/ExampleDataPilotSource.oxt" > ERROR: unopkg cannot be started. The lock file indicates it is already running. If this does not apply, delete the lock file at: > ~/lo/core/workdir/CustomTarget/odk/build-examples_java/user/.lock ~/lo/core/desktop/source/pkgchk/unopkg/unopkg_shared.h:44 > make[2]: *** [Makefile:227: ~/lo/core/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/DevGuideSpreadsheetExamples/devguide_ExampleDataPilotSource_register_component.flag] Error 1 So make sure the `make` invoked from those CustomTarget_odk/build_exmaple* does not inherit any -j flag from the outer `make`. (I had observed this with an explicit `make -j4` and --without-parallelism, but this should also be an issue for the implicit parallelism from the default --with-parallelism.) Change-Id: Iff368dbbcad01d3841d63c2985639ba6a3dec1f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103504 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-27Fix an odk/examples dependencyStephan Bergmann
ImageShrink.oxt is created in the org/openoffice/comp/test sub-make, and CustomTarget_odk/build-examples_java had once failed for me with > make[2]: *** No rule to make target '~/lo/core/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/bin/ImageShrink.oxt', needed by 'ComponentsThumbsExample'. Stop. Change-Id: I926d0691e7eee3506d4afe2eda1a2fc873422e18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103502 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-15Fix typosAndrea Gelmini
Change-Id: Ia0a24bf32290ecb6b6153ba412d5e282f56d92f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102693 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-31Remove remains of private:image/ via ImageIdentifier addon propertyMaxim Monastirsky
This is broken since commit 5c39b28a87060f80404079ab77604f664addb063 ("tdf#96059 Replaced imageproducer with CommandInfoProvider") but so far no one complained (maybe because the usefulness of such internal images from extensions is questionable at least). Given also that the whole ImageIdentifier feature (even its still working part) is obsolete since OOo 2.0.3 (according to the OOo dev guide), and that the availability of a particular image from an internal hardcoded image list by a particular numerical id is more an implementation detail, let's just remove the broken code instead of fixing it. In the meantime, the code was also copied into the newly introduced notebookbar addon code, so I handled it there too. There are also the registry schema and a sdk example that mention this feature, and need to be adjusted. Interesting that the particular example used there - private:image/3216 is actually broken since 2011 with commit 2559cab126f81375197051fb5b07ba6abb9efc77 ("FDO#42454 - EasyHack: remove code associated with unused icons"). Change-Id: I968b4fb8c5b207654476dd92c57d8db0815520ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101529 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-08-31Remove empty ImageIdentifier properties from sdk examplesMaxim Monastirsky
Change-Id: Id1a6b4fc6e156f67550458b4b7e4b1ffe32f812a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101691 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-08-29Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I255b7a0873170d956c914d76fd363e358f807d7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101596 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-21Fix typosAndrea Gelmini
Change-Id: I8dc0cdcfe6bd90efc596df28e6c6d968b92618b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101098 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-07-22Remove obsolete dynamic exception specifications from SDK example C++ codeStephan Bergmann
GCC 11 trunk g++ defaults to C++17 now, so that CustomTarget_odk/build-examples and CustomTarget_odk/build-examples_java would now fail with "error: ISO C++17 does not allow dynamic exception specifications". 550e0e42d9ccef1244299b2d6cbda18549f8af19 "Remove dynamic exception specifications from cppumaker-generated code" had long since removed the exception specifications from the underlying (C++ classes representing) UNO interface types, so just remove them from the SDK example code, too. An alternative would have been to make sure those CustomTarget use an old C++ compiler standard. However, testing that the examples work against a new standard has probably similar merit to testing that they keep working against some obsolete standard. Change-Id: I8ec9ac2f9ced7bd1b746fb00d9bce94bf6aedda5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99218 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-07Typo: pargraph->paragraphJulien Nabet
Change-Id: I7749951d829eb8aaeacdca0fd66d41cf9d6a1613 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98251 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-05-06Move all public Java classes to libreoffice.jarSamuel Mehrbrodt
This moves the classes from juh.jar and ridl.jar to libreoffice.jar The goal is to have one single jar (and Java module, will be added later) which developers can include to work with LO. juh.jar and ridl.jar are kept as basically empty jars with libreoffice.jar on its classpath to keep backwards compatibility. This is a continuation of ae855bf48163ff64d94cfc34aff8e37abdb5518d and a preparation to have Java 9 module support. Change-Id: Ifbbfb97f60373d14256e62ae3122913bd17d5bbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91930 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-23make spinbutton demo wide enough to useCaolán McNamara
Change-Id: Ibfd0e27b0b382fb6e0f71bfd4d9555998b03ded5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92754 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-02-24Fix typoAndrea Gelmini
to complete: https://gerrit.libreoffice.org/c/core/+/89082 Change-Id: I8363f05f15c8d4ef032ccc8d469dc29231d74ca7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89360 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
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>
2020-02-10Cleanup: Move files to ridljarSamuel Mehrbrodt
These files are now part of ridl.jar instead of jurt.jar, so move them accordingly. Follow-up cleanup for ae855bf48163ff64d94cfc34aff8e37abdb5518d Change-Id: I01df60d99f5296b6252b260f52160c3e62f4b8dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88007 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-02-04tdf#117331 Merge jurt and unoil into ridlSamuel Mehrbrodt
jurt.jar and unoil.jar are kept as effectively empty jars, each with a Class-Path: ridl.jar in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or without also loading ridl.jar) will still have access to their content. Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi) are not part of the URE, but are now made available by URE's ridl.jar. This should probably not cause problems in practice. At least for now, we seal exactly those packages in ridl.jar that were originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now, but that would be mildly incompatible, as it would prevent 3rd-party code from introducing additional UNOIDL entities in the relevant namespaces (even if that is something we do not want 3rd-party code to do anyway). However, some JunitTest_jurt_* define classes in those sealed packages. In the past they got away with that by using gb_JunitTest_use_jar_classset,*,jurt. Instead they now need to gb_JunitTest_use_jar_classset,*,ridl and drop the gb_JunitTest_use_jar,*,ridl. But the former only makes available the classes that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use gb_JunitTest_use_jar_classset,*,jurt but don't seem to acutally need it; lets leave that for a follow-up clean up.) As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/. Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a Co-authored-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-28Remove misleading commentStephan Bergmann
...that had not been adapted when the corresponding #ifdef had been changed in 2087484c65a3d5e75a9e8ad116d11a4e13366219 "use consistent #define checks for the Windows platform" Change-Id: I5afec630311201269f60b50271f31a36edaf2333 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87593 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-17odk: docs: remove the confusing sentence about "user installation"Michael Stahl
Better not mention an undefined term than to leave people guessing what it means. Change-Id: I589475303e215bd12cdc92e0f858d048052b6da6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86987 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Michael Stahl <michael.stahl@cib.de>
2020-01-06Avoid $(shell $(gb_MKTEMP))Stephan Bergmann
...which, when included in a ifneq ($(MACOSX_SHELL_HACK),) block, appears to be executed every time the surrounding odk_build-examples_test macro is evaluated, even in builds (like a Linux build) where MACOSX_SHELL_HACK is empty. (And which thus caused spurious empty gbuild.* files to be left behind in the tmp dir by such builds.) Change-Id: I8ef0204817f089cd977340a0ce3b6a17a347b209 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86279 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-06Fix MACOSX_SHELL_HACKStephan Bergmann
...so that it is set and actually takes effect when the definition of odk_build-examples_test is expanded Change-Id: I0a4ca22f3b7b17d802dae9195954b030cde9ddac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86251 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-02Bump copyright year to 2020Adolfo Jayme Barrientos
Change-Id: I6fb736591f32907c8977fbac8fbf1dcbaef1bb97 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86092 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2019-12-19sal_Char->char in lotuswordpro..odkNoel Grandin
Change-Id: I5a7bd149554d24276a67437b654f8ffd2610a276 Reviewed-on: https://gerrit.libreoffice.org/85478 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-18Fix typoAndrea Gelmini
Change-Id: Ia721484c9c39d62e939bb3f5628c8dcaa89d5603 Reviewed-on: https://gerrit.libreoffice.org/85417 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-12-18Fix instructions for setting up the SDKStephan Bergmann
(see the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2019-December/084013.html> "Beginner's question about installing Libreoffice SDK") Change-Id: Iea0c394ec052587cdf4ba2a6a7ab38f4214ccbf0 Reviewed-on: https://gerrit.libreoffice.org/85374 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-17Cosmetic documentation fixesStephan Bergmann
consolidate on "Linux", "macOS", "Unix-like systems", "Windows", "Xcode" Change-Id: I448adee41cd557544b9c717ce7663c6fd08a7270 Reviewed-on: https://gerrit.libreoffice.org/85332 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-05Fix typoAndrea Gelmini
Change-Id: I387f408aefc30132a65088bec05c733346e9d5a4 Reviewed-on: https://gerrit.libreoffice.org/84486 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-19loplugin:fakebool (clang-cl)Stephan Bergmann
...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-11-17cid#706181 Use of untrusted string valueCaolán McNamara
use an annotation here and add one to the windows equivalent Change-Id: Ife54949c2e89ae606d7931be82807db4bbb132dc Reviewed-on: https://gerrit.libreoffice.org/83024 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-01odk: fix for change directory in complextoolbarcontrols sampleVasily Melenchuk
On Windows classical "cd" command does not change drive automatically. So if OO_SDK_OUT folder located on another drive than SDK_HOME we will receive confusing buid errors. To avoid this for Windows configuration we should use "cd /d". Change-Id: I22908d49fc915d3a834972357934349ba82bbec5 Reviewed-on: https://gerrit.libreoffice.org/80827 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-10-23ODK: cleanup windows linker debug argsThorsten Behrens
This was a somehow confused & partially commented-out setup Change-Id: Iad5ef6721cda6f85ded3296650ee9a7df9ec59fd Reviewed-on: https://gerrit.libreoffice.org/81333 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-19Fix typo and dotsAndrea Gelmini
Change-Id: Ia34130dbab42d61074a73a2b16e03360b5b123b6 Reviewed-on: https://gerrit.libreoffice.org/81086 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2019-10-12rtl/stringconcat.hxx is not part of the URE interfaceStephan Bergmann
(and #include's of it in include/rtl/*.hxx are already guarded with LIBO_INTERNAL_ONLY) Change-Id: I9224f71a244a69ef69406ea3a5879b66b3cae3a3 Reviewed-on: https://gerrit.libreoffice.org/80666 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-11simplify "a = a +" to "a +="Noel Grandin
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-10-09Make odk build-examples work on macOS 10.15Stephan Bergmann
...which apparently got even stricter with unsetting DYLD_LIBRARY_PATH when starting a shell, so the old workaround from 9ac2aad4c1cd0f8d513c02a897da90c42f2fa961 "OSX fix ODK example builds with enabled SIP" no longer worked for me (and CustomTarget_odk/build-examples_java failed with > dyld: Library not loaded: @__VIA_LIBRARY_PATH__/libreglo.dylib > Referenced from: /Users/stephan/Software/lo/core/instdir/LibreOffice6.4_SDK/bin/idlc > Reason: image not found ). Building on macOS 10.15 now requires to build a shell from upstream sources and pass it into toplevel make as a SHELL=... command line argument (but which I at least already needed to do anyway, to preserve a global DYLD_LIBRARY_PATH pointing at a nonstandard libc++, when building external/firebird). Change-Id: I00ec0649fafa1842bed3f2a1258e3184d6bcfdd1 Reviewed-on: https://gerrit.libreoffice.org/80532 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>