| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
using both --host=aarch64-pc-cygwin and --build=aarch64-pc-cygwin on a
suitable system.
Change-Id: Id11e25b03de8dd8dd52c63e7a06d57d44e3fce33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150053
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
* 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>
|
|
...as a replacement for the legacy regview
Change-Id: I1e1eecb45f27422727f28feb19c2479af867bd79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132816
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...it is a build-time tool used from solenv/gbuild/UnoApiTarget.mk, and should
be of no value for users of LO (or of the SDK). It was presumably a historic
mistake that its predecessor regcompare was included in installation sets in the
first place. (The only mention of it in the Developers' Guide, which only
acknowledged its existence without giving any details how to use it, has been
removed in
<https://wiki.documentfoundation.org/index.php?title=Documentation/DevGuide/Writing_UNO_Components&oldid=492551>
"Drop mention of build-time tool unoidl-check that should not be part of any
installation sets".)
Change-Id: I626e22fa18ad900af150afe29a36aa1ceaf5e259
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132814
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 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>
|
|
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>
|
|
...that were missing from 3de594d3347ead24f3211714f0e0010c1434cdf2 "More tests
to suppress (all .PHONY test targets should be covered now)" (and one wasn't
even properly marked as .PHONY). Thanks to Rene for spotting.
Change-Id: Ieed81a3999921bdfe9bca96c6002d8906b2ddfad
|
|
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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, c5f974287fd04bb529de145113133b9e35687702 "INTEGRATION: CWS jsc3:
#i62434# copy libsalcpprt.a" added the library (under Linux) and
6db9c5af960f9787e33e4addc56bddbb1695a402 "INTEGRATION: CWS jsc3: #i62434# extend
link options for executbales to link libsalcpprt.a, LINUX only" added its use to
odk/settings/settings.mk, but fc0ca57f2cd649c6330171445a06b80e2143a0e9
"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>
|
|
...as the latter was the more flexible replacement for the former for LO-
internal use already. The only gotcha to watch out for is that unoidl-check
cannot be used to check "naked" .urd files, but only ones where the content has
been moved to /UCR via regmerge.
Leave registry/CustomTarget_regcompare_test.mk around to verify that
unoidl-check behaves the same as did regcompare on those old-format .urd/.rdb
files.
Change-Id: Ic13ede48535bf942126c810d88bac7e4081d984e
|
|
Change-Id: Ie6f3404ef034bae2550ca451909fcf120a70a78b
|
|
Change-Id: Ib6e7a456b2f39c47da44552184669005d18d4fa4
|
|
Change-Id: Ia54def7a404e07974eb1e8a556f4659cd974e7f8
Reviewed-on: https://gerrit.libreoffice.org/7081
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Matúš Kukan <matus.kukan@collabora.com>
|
|
Change-Id: Ic27986d8d45f61facedf2400b77334aaf1da7c1e
|
|
Introduce SDKDIRNAME as a configury variable and use it instead of the
gbuild gb_Package_SDKDIRNAME. Then we can easily construct the
SDKDIRNAME_FOR_BUILD variant that is needed to find the specially
named SDK in instdir on OS X when cross-compiling.
Move the version number section in configure.ac earlier.
Change-Id: Iee3db1a50ad4c7a9f91bbc5e0d0b01d76a76f701
|
|
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 66eedcee026459b2827a46d8ebc73749e3c71453
but has apparently never actually been used in the bundled SDK
makefiles.
Change-Id: Ifa6cab95be6575ac26840250ad717d94e15bea66
|
|
Change-Id: Ib451bdb3c1c2ca42347abfde44651d5cf5eef4f3
|
|
Change-Id: I9d1e232f2fea779f111067b588bbb36411039de2
|
|
Change-Id: I1613ce8cf9b8248bb5d5e546df7310154e11b830
|
|
Change-Id: Ic3f2d42121b5423d67c4c79302b02ac495ac9640
|
|
Change-Id: I49204b3518c47614e591de47a916901861331673
Reviewed-on: https://gerrit.libreoffice.org/3777
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I93176653935b6ccfd4181e6086444fbe7475f2b0
Reviewed-on: https://gerrit.libreoffice.org/3775
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I121a4ad5d7cff54b914796142fa7c50006856300
|
|
Change-Id: Id53ab5de54ff8e86a39685b370b1114666755cfe
|
|
Change-Id: I0a814e3f5605340f00d4b48e83ce26792abec067
|
|
These are put into uno_loader_classes.zip, which is then not used at
all, and odkcommon.zip, which is used for creation of install sets.
Seriously?!
Change-Id: I28b5bc73857cf524fb12f7918acd2891ff12d166
|
|
Change-Id: Ibdbe04028ad9648af011da51b562cc6aa5e4849b
Reviewed-on: https://gerrit.libreoffice.org/3578
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I474f6e7a45d09683eb0dd7172114407c9dca84d7
Reviewed-on: https://gerrit.libreoffice.org/3571
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I434508057dbfab9410d8f7fc3844c45cd4201b11
Reviewed-on: https://gerrit.libreoffice.org/3588
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I51841a8c92cb73912757fcc0766b11d8f9be4b77
Reviewed-on: https://gerrit.libreoffice.org/3587
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I1b2e224cb3b709e3c693f18918dcef5e0304894e
Reviewed-on: https://gerrit.libreoffice.org/3536
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
Change-Id: Iee97a510be822836b2115f50d0b1c9e7e14b5e1a
Reviewed-on: https://gerrit.libreoffice.org/3534
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
Change-Id: I3d5d841d094f397130e37799a2f26e4d85f7c136
Reviewed-on: https://gerrit.libreoffice.org/3533
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
Change-Id: I929384077255b2fd944abf2da573c66572dec62b
Reviewed-on: https://gerrit.libreoffice.org/3532
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
Change-Id: I7546e8938ba41e1462e704bd0405c5a887151d7b
Reviewed-on: https://gerrit.libreoffice.org/3531
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
Change-Id: I1d747fec9b1bf2aeef2a1886981f7f07a338ea12
Reviewed-on: https://gerrit.libreoffice.org/3530
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
Change-Id: Ia57ed471294595f1a8ee0aa0af05f3b82d439393
Reviewed-on: https://gerrit.libreoffice.org/3529
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
Change-Id: I58f0cd2248310fd7c5f1c82a6d10acc5a2446169
Reviewed-on: https://gerrit.libreoffice.org/3528
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
This is in preparation for my plan to move stuff out of odkcommon.zip
and install it using filelists. The moved files will be in
$(INSTDIR)/sdk, not in the Zip's workdir, so we must look for them in
both places.
Change-Id: I7dd224c9067f2dbb522b87b7057ddc02a5fa0cad
Reviewed-on: https://gerrit.libreoffice.org/3527
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
This tests for problems that cannot happen any more since we now build
the Zip file from the same enumeration as the delivered headers, so they
cannot be different.
Change-Id: I0aacb2b8b1b6f187674b3a16b0fe7cb474e1b8c7
|
|
Change-Id: I020c589ce2cf223b16c81087df3eb819569f1d8c
|
|
Change-Id: I8e8de7f2bb87cce7916c7c2df24c1b0ddaea55c0
Reviewed-on: https://gerrit.libreoffice.org/2288
Reviewed-by: Peter Foley <pefoley2@verizon.net>
Tested-by: Peter Foley <pefoley2@verizon.net>
|
