In the past, LibreOffice cross platform .NET support could correctly
build binding files, but these files were not shipped. This patch fixes
the issue, and ships these files, as described below:
$ ls instdir/sdk/dotnet/
LibreOffice.Bindings.0.1.0.nupkg
nuget.config
$ ls instdir/program/dotnet
net_basetypes.dll
net_bridge.runtimeconfig.json
net_uretypes.dll
net_bridge.dll
net_oootypes.dll
Change-Id: I947aafbf45436855dfdb7ab5f3268f42b8a66511
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208294
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This commit adds an --enable-cli/--disable-cli switch to autoconf to
control generation of the old CLI bindings (Windows only). It is
enabled by default, to not be a breaking change to users just yet.
Over time, when the old bindings are deprecated in favor of the new
.NET bindings, it could be set to disabled by default.
Change-Id: Ib60b372459cb0c735275ed17d004d037279357eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168751
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This patch adds a new Python helper script to generate Addons.xcu for
LibreOffice extensions. The script works like a wizard, and asks user
about the needed details. It provides these options for the application
module context:
1. Writer
2. Spreadsheet
3. Presentation
4. Draw
5. Formula
6. Chart
7. Bibliography
After selection of the module, appropriate Addons.xcu is generated, and
user is asked to choose between 'desktop' or a custom folder to save the
resulting file.
Change-Id: I22a878f0bde19a870674a357d7085ad3c12fc50c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163382
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
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>
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
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>
... since archs with the "Zero VM" take loooong otherwise and eventually
gets killed after 150 minutes of "inactivity" (no output)
Change-Id: If421378920c791fdc5d165cc452bdd40e136c8d1
This is quite confusing: the gb_Helper_register_packages_for_install
odk_headers does not actually use the Package odk_headers, but the
PackageSet odk_headers, because the name is the same and the PackageSet
directory comes first in the search path.
This means that the Package odk_headers_generated is installed despite
there being no obvious reason why.
The PackageSet doesn't provide much value here, so just remove it.
Change-Id: I564f3b9fc6acaabe700328bc8c3db70c3b2de0cd
...containing replacements for global operator new/delete (that can be linked
into executables), but which is no longer used. The mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2012-March/028690.html>
"operator new no longer routes through rtl_AllocMemory in libsalcpprt under
gbuild link rules" has the details of how this was used on some platforms (but
not on others) before the switch to gbuild, and has been "lost" ever since---but
apparently a loss not mourned much over the years.
For the SDK, c5f974287f "INTEGRATION: CWS jsc3:
#i62434# copy libsalcpprt.a" added the library (under Linux) and
6db9c5af96 "INTEGRATION: CWS jsc3: #i62434# extend
link options for executbales to link libsalcpprt.a, LINUX only" added its use to
odk/settings/settings.mk, but fc0ca57f2c
"INTEGRATION: CWS jsc21" removed that use again (for no documented reason). So
this is an incompatible change, but unlikely to actually affect any users of the
SDK.
Change-Id: Ia38b4c439f21fca3f5d9af7d1a34054e992054e9
Reviewed-on: https://gerrit.libreoffice.org/31810
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
- remove Package_readme, use generated files from WORKDIR via include
path
- Package_license and Package_files deliver to INSTDIR
- split up Package_odk_shared_readme to have extra Package for
generated files
- gb_Extension_LICENSEFILE_DEFAULT points to INSTDIR
Change-Id: I019d3431e30d982e887ae0000c755e0d61f98893
This is somewhat annoying since it requires re-introducing stupid
directories in scp2, but if the executables should be put in INSTDIR
directly then the Package_bin needs to go.
Change-Id: I893694c7f9d4cb5b9ef8ec4a3d30e08536223740
This was added in commit 66eedcee02
but has apparently never actually been used in the bundled SDK
makefiles.
Change-Id: Ifa6cab95be6575ac26840250ad717d94e15bea66
This is a workaround for problems with file names containing $ in
gbuild. And it does not matter much in this case, because the classes
are never used during build, so there is no need to have exact
dependencies.
Change-Id: Ibeb30257a62ed13744dc4fe987830d1e5a4102b0
- UnoApi: stop delivering IDL files to $(OUTDIR)/idl
- add ZipUnoApi to package IDL files for SDK
- convert udkapi and offapi to ZipUnoApi and package them in scp2
- odk: remove ugly CustomTarget_idl that uses "find"
Change-Id: I8dc4e0e7d0dc51c1abf18f31bfe095760d3c2104
Hossein