| Age | Commit message (Collapse) | Author |
|---|
|
This patch includes:
1. CustomTarget to build and place the LibreOffice.Bindings NuGet
package in <sdk>/dotnet/
2. net_bridge (.NET library) to declare bootstrap() on the C# side,
and net_bootstrap (C++ library) to wrap bootstrap() on the native side
3. Changes to LO SDK scripts to find .NET SDK and DOTNET_ROOT on the
users machine
Change-Id: Ia29ae56a2ad0f808f1563ef6167a3bd7c476642e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170172
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
* Client code must replace uses of idlc and regmerge with uses of unoidl-write,
see the changes to odk/examples/ and ure/source/uretext/ in
40f2aee6584eafcf4cd1d95fcf1f775e5435440d "Provide unoidl-write also for the
SDK" for examples.
* The new types.rdb format is not compatible with LibreOffice < 4.1. Clients
generating extensions containing such files are advised to use appropriate
LibreOffice-minimal-version elements.
* For compatibility with old extensions, reading the legacy types.rdb format is
still supported.
* The SDK no longer ships an idl/ sub-directory containing the udkap and offapi
.idl files (as, unlike idlc, unoidl-write does not need them).
odk/config/cfgWin.js had to be adapted to look (somewhat arbitrarily) for an
examples/ sub-directory instead of idl/ when checking for "an sdk folder".
gb_UnoApi_package_idlfiles became unused and has been removed.
* The idlc and regmerge executables have been removed. Module idlc has been
removed except for idlc/test/parser/, which is also used by
CustomTarget_unoidl/unoidl-write_test, and which may eventually be moved into
module unoidl. Module external/ucpp and the corresponding configure options
have also been removed.
Change-Id: I42a0231699b863b5ebe2bee63bc32c8f79278cc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122363
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after the new types.rdb format that unoidl-write generates has been used
internally since LibreOffice 4.1 in 2013; following up on
6db34b6b33ba8e3b13683efd05df8441b87e9c92 "Directly build UNOIDL .rdb files from
.idl files" and its "The legacy tools idlc, regcompare, regmerge, and regview
are still contained in the URE or SDK for now."
The tools idlc and regmerge are deprecated but still shipped in the SDK for now.
The plan is to drop them completely for LO 7.5.
odk/examples/ and ure/source/uretest/ are adapted to use unoidl-write instead of
idlc and regmerge:
* unoidl-write does not use a C preprocessor and the # directives in .idl files,
it supports reading a single .idl file (containing an arbitrary number of
declarations) or a directory tree where each directory corresponds to a UNOIDL
module of the same name and each .idl file contains the declaration of the
(non-module) UNOIDL entity of the same name. For some of the odk/examples/,
that required moving individual .idl files into sub-directories named after
the respective modules. In odk/settings/std.mk, definitinos of IDL and
REGMERGE have been replaced with a new UNOIDLWRITE.
* unoidl-write always enforces reserved UNOIDL identifier restrictions (see
04af4e4f55f3ef319a78edd4d0109e2e7eba90b6 "[API CHANGE] Fix all bad UNOIDL
identifiers across offapi" and 620179240670bd00f60555f1f5c5b0268492f97c
"Enforce the UNOIDL identifier scheme") (which idlc only enforced optionally
with -cid -we). That required renaming "my_module" in
odk/examples/DevelopersGuide/Components/CppComponent/.
* The new types.rdb format is not compatibly with LibreOffice < 4.1. Clients
generating extensions containing such files are advised to use appropriate
LibreOffice-minimal-version elements.
Change-Id: I1a248fd96e86ecbf407f829bc100d44bfe7f4e7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130533
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
|
|
Only on macOS, the SDK used to expect javac etc. in a Commands sub-dir (which
Apple's JDK 1.6.0 has but Oracle's JDK 1.8.x don't). However, at least both
Apple's latest JDK 1.6.0 (as available via <https://support.apple.com/kb/DL1572>
"Download Java for OS X 2015-001") and any recent Oracle JDK 1.8.x (like
jdk1.8.0_121.jdk) have a Home sub-dir that contains a "standard" sub-tree with
bin sub-dir etc., like on other platforms. So consistently make the SDK use
that instead.
This removes the JAVABIN Make variable from settings.mk. It is assumed to not
be used by client code.
Change-Id: Ie0ad647f489528444dfd399c2f00500b772d3288
|
|
...in which case the corresponding tool is located on the PATH
Change-Id: I4242180fbbc829f11aa1a12cf1e6b9f0a21ab7c6
|
|
See http://listarchives.libreoffice.org/global/users/msg49357.html
odk/settings/std.mk currently adds each .class file separately,
therefore having to be updated manually any time one class or
anonymous class is added, removed etc.; all the .class files in
com/sun/star/lib/loader/ are needed in the jar anyway, so use a
generic makefile rule.
Change-Id: I3819ab94e2c056220993971de44408e46a4559ed
Reviewed-on: https://gerrit.libreoffice.org/28317
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
...that was added with both c4c10c17adfb139a208deeb1a47a9fcad924b9c3
"INTEGRATION: CWS sb87: #i88687# let Loader call new unoinfo instead of old
juh.jar UnoInfo.getJars" and 9d53b3321881bd54526f08a9219c539c1430f2b5
"INTEGRATION: CWS jsc21"
Change-Id: I355cbd933e3cff76416d02af8d6717326e0f3cb7
|
|
...that was introduced with abbf4777f29374025d576ef8daa3f6dcba02ddf5
"cid#1326844: DP: Use doPrivileged"
Change-Id: I8cd4d947b258313d4d171c5888490d1a860ebee7
|
|
Change-Id: Id8c6082b4b90c3020e1187dd311f0afd0320d155
|
|
Change-Id: Ifd40e523f146ee26f49fe443e2455d053c7b6bfc
|