which means I can remove one usage of gb_Library_set_plugin_for, which
is blocking linking the sw module into --enable-mergelibs=more

Change-Id: I8c199421c66de2dcf339ccc2d5cb9340d3bea914
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164429
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

I've decided this is not an API change because there exists
offapi/com/sun/star/script/vba/VBATextEventProcessor.idl

This patch allows New, Open, and Close events to be
sent to VBA macro event handlers.

I tested with DOCUMENT_OPEN.

Amazing - all this stuff is here in place,
but isn't properly wired up. How can so much
ground-work be done without it ever being functional?

I don't think this has ever worked,
and the same problem/code is seen in OpenOffice.

The service names were already mismatched in the initial patch:
commit fc135411fa926f4d89e98378d113f597af79e2a2
Author: Daniel Rentz on Tue Jul 6 19:34:53 2010 +0200
    mib17: #i112634# add VBA sheet event handling,
           based on a patch from Noel Power

https://bz.apache.org/ooo/show_bug.cgi?id=112634
says "Additionally I added the hooks for vba for word
( but they are compiled out for now )"

Enabling this will open up the doors to a lot of
untested code I think.
I had to move initialization of mxVbaEvents
because it was being set without a VBA project,
but it didn't work to put it in VbaGlobals like Calc does.

Change-Id: I08cc0e33444dc7dfaac82cf6cebb1a89dbb69faa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140801
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Instead of trying to make up BUILD_TYPE items to match complex
build conditions and then patch the component file with it, filter
the component files based on the unique implementation name and
an <optional/> tag. Currently these optional implementations are
grouped in external files with an identifier.
Originally the optional implementations were automatically iden-
tified by adding them to any external file, but this behavior is
too easy to get wrong. Even better: if need arrises, one can now
easily implement a feature to add implementation names directly
using gbuild calls, instead of grouped files.

The basic mechanism is to collect all optional implementations,
remove the needed ones from that list and then filter-out all
implementations not needed (AKA the rest of the list).
It's no problem to have the same optional implementations
selected in multiple files. This is especially used by the
vcl.common component in a later patch.

For gbuild this adds gb_Library_add_componentimpl. The component
parameter for the call is explicitly omitted, so you must call
gb_Library_set_componentfile before selecting any optional
implementations. The strict naming is also enforced by appending
the identifier to the component file name.

This replaces commit 65c0887bca2909b2046eb5aa4aaace0cc320c3f2
("Allow for conditional parts of component files").

Change-Id: I0261cadce8bdfebb6b3ec96669ec378a5c1d9699
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126891
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins

1c9a40299d328c78c035ca63ccdf22c5c669a03b "gbuild: create services.rdb from built
components" had moved parts of svx/util/svx.component and sw/util/sw.component
into additional, conditionally included component files (and which this commit
moves back into the original component files).  But that lead to multiple
<component> elements for a single library in service rdb files, which was
unfortunate for several reasons:  For one, while the code in
cppuhelper/source/servicemanager.cxx happened to support that, it was not
guaranteed to support it, so this relied on an implementation detail of that
code.  And for another, for that to work, all the component files for a
library had to provide identical environment, loader, and prefix (if any)
attributes, but which was not verified and thus was brittle.

Instead, introduce a CONDITION attribute for the <implementation> elements in
the source component files, which decides whether or not such <implementation>
elements are passed through (after dropping the CONDITION attribute) into the
processed component files (in workdir/ComponentTarget/).  (The attribute
is spelled all-uppercase to make it more obvious that it is special syntax that
is not simply passed through to the output component file.)  For now, such a
CONDITION attribute must have a value that matches BUILD_TYPE:x for some
feature x in $(BUILD_TYPE), but the syntax can be extended if the need arises.

(gb_Library_set_componentfiles is thus no longer needed and has been removed
again.)

Change-Id: I360cf4cc0f3a2a738113d430891500715a8fe3a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126560
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

... and introduce the --enable-services-rdb-from-build option.

Currently the build handles global build options redundant
in a few places:

* in Repository*mk + modules - the "real" build dependencies
* the full services.rdb generation
* the static UNO constructor map generation

Also the component files don't reflect the really built components
and so the RDB services generation must handle the whole options
to select the correct components.

So this optionally replaces the latter two by generating the list
of components and it's constructors from the build itself. As a
consequence, component files must now be split, so they reflect
the real components in the libraries, otherwise the static
constructor list will have missing symbols. IMHO this is more
natural, as it happens in the same place already handling these
build options for the sourcecode.

This also adds a convenience helper to add multiple component
files: gb_Library_set_componentfiles

This is WIP and currently just works for the stripped WASM build,
which introduces many more split component files in later patches.

It also explicitly filters the gb_Rdb__URECOMPONENTS and the
CppunitTest related components from the services.rdb. Maybe there
is a good way to do this properly.

Change-Id: I1b38a6f2c1e5221f18d7e5e756c30263b555d962
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126185
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>