VAR=$(shell … ) will run the shell command each time the line is parsed,
i.e. for each include of the settings.mk from the examples. Use
simple/one-time expansion using := avoids that.

Change-Id: I46e6c486fbbe03bba37436d4ca98ddd0b6562ad3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168091
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>

has already been unnecessary since over 15 years/was the default since
OS X 10.4 (2005) along with ignoring the corresponding altenative
(-multi_module) switch, from man ld:
-single_module
    This is now the default so does not need to be specified.

-multi_module
    Multi-modules in dynamic libraries have been ignored at runtime
    since Mac OS X 10.4.0.  This option is obsolete.

Xcode 15 now warns about it being obsolete, so remove it.

Change-Id: I4d4aab452a330c3c4ec97da4232c3af6350c0ff4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157407
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@neooffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>

See https://www.gnu.org/software/make/manual/make.html#Conditional-Syntax

Change-Id: Iddd4ee2d42c83e6d661ef7d91c93a06caf307001
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141708
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>

Change-Id: I95c78d1346d354b755aeecaa1e6c9d789be0b693
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132905
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>

...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