Age | Commit message (Collapse) | Author |
|
* Use <iostream> instead of <stdio.h>
Change-Id: I5cc70613c0b183c24bfa73b779dac3b382b31c93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123328
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Fixing the license statement for the 'Convertor.cxx' and 'Makefile'
according to the '/TEMPLATE.SOURCECODE.HEADER'
This example was added in 83b529d88388c7c8e0563242a030063bd95c4bed
Change-Id: I654d641999aab6951ad21f84fd75e080bb709ec4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125128
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
* Add Convertor.cxx
* Used Makefile from DocumentLoader with some changes
* Updated odk make files
* output.pdf is generated from the input odt file
Change-Id: I3e46f2895443f75b2f3815280b0f793bca5138e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123736
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
* Remove unncessary C-style cast from DocumentLoader.cxx
* Remove trailing whitespaces from Makefile
Change-Id: I7cff589353d3e40301cf45ce0a76e0c75beddf13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124115
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I62e12aed5bc67119433c39ff333f69b79944dca3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123318
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I15d56d133cf464a3cb6483be785b1259c7f35b43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123120
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I6ebbd0ece563f0d877b03389fa9a96311cd207cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122867
Tested-by: Jenkins
Reviewed-by: Roman Kuznetsov <antilibreoffice@gmail.com>
|
|
This failed with GWL_WNDPROC being undefined in 64-bit builds. See the note at
<https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowlongptra>:
"To write code that is compatible with both 32-bit and 64-bit versions of
Windows, use SetWindowLongPtr."
Change-Id: I7abcc681b4daf459eb0c0481266949c75ecf4dda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122341
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(where css.util.Color is a typedef for UNOIDL LONG). This caused issues on
Windows, where in C/C++ sal_Int32 is a typedef for long rather than int.
Change-Id: Ic0407674d06a219210d7f0448100005d7135eb79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122340
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Id10dc2ef13f54a148a800003cc4bd88ca1a0056f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122233
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
(trying to change the actual content of those lines would otherwise trigger our
"indent with Tab" git commit hook)
Change-Id: I97449056eb7850d3993fa5ac565e342d0bcbf200
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122093
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia70268084603db3329d276533a9351e6c1eebbca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121894
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...introduced with aaebbb0e597bfeb8e1c545130a0d17a55b164228
"INTEGRATION: CWS jsc21" (but which never caused an issue as cppumaker generated
output for all of $(COMP_RDB) anyway when the undefined $(TYPESLIST) didn't
contribute anything to its command line)
Change-Id: Ic6792ad9edc159c02d307ca72500605bc3c38077
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121851
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It had been added together with odk/examples/java/MinimalComponent/Makefile in
ff4c86ff37af5136466d49a9fb394974ee62cb0f "Added an example for a minimal UNO
component", and it apparently is an Ant build script that shall do the same as
the Makefile. However, it is apparently unused: For one, it does not
appear to get referenced from anywhere else in the code or to get mentioned at
<https://wiki.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide>.
And for another, it would apparently only work on Windows (using e.g.
"${ODKPATH}/windows/bin/idlc.exe"), but would typically fail even there with
something like
> > ant -f BuildMinimalComponent.xml
> Buildfile: C:\lo\core\instdir\sdk\examples\java\MinimalComponent\BuildMinimalComponent.xml
>
> init:
>
> unoidl:
>
> BUILD FAILED
> C:\lo\core\instdir\sdk\examples\java\MinimalComponent\BuildMinimalComponent.xml:35: The directory D:\cvs\api\odk\WINexample.out\misc does not exist
due to the hardcoded D:/cvs/api/odk paths.
Change-Id: Idd020bcf1a2383295704b208d3ac2be047f270ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121050
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Instead of just adding a license header,
2b4fd2c89a38ccac13c72f2e94501a8702e7da4b "re-base on ALv2 code" had apparently
erroneously overwritten this file with the content of the completely unrelated
odk/examples/java/MinimalComponent/BuildMinimalComponent.xml.
Change-Id: Iee6dcb528dbb444a132c27e7183b3957319882c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121037
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I0a8ce634944df4af5c9e2000af5f6429b4e40b2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119097
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
* 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
|
|
Change-Id: I809231e7e6ceaa93c2d0b523de8a4b93b07b449c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118841
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
* 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>
|
|
* 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Idf71c662138c281333a83cc76a9d75cbf086f362
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110236
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
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>
|
|
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>
|
|
...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>
|
|
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
|
|
Change-Id: I427263ee98206c00cd2b3392fc9f2f55ad1ded5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105692
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Ia0a24bf32290ecb6b6153ba412d5e282f56d92f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102693
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Change-Id: Id1a6b4fc6e156f67550458b4b7e4b1ffe32f812a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101691
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
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>
|
|
Change-Id: I8dc0cdcfe6bd90efc596df28e6c6d968b92618b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101098
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
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>
|
|
Change-Id: I7749951d829eb8aaeacdca0fd66d41cf9d6a1613
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98251
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Change-Id: Ibfd0e27b0b382fb6e0f71bfd4d9555998b03ded5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92754
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
...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>
|
|
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>
|
|
...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>
|