Directly build UNOIDL .rdb files from .idl files

...via unoidl-write and the new source-format registry provicers, instead of
using idlc to produce .urd files, regmerge to merge them into legacy .rdb files,
and unoidl-write to translate those to new UNOIDL .rdb files.

gb_UnoApi and gb_InternalUnoApi ctors take an additional argument now that is
the path (below $(SRCDIR)) of the source-format registry from which to obtain
UNOIDL entity definitions.  It can either be an .idl file (in which case no
*_add_idlfiles calls should be used and the resulting .rdb will contain all the
entities from that one .idl file; used in some tests to conveniently define all
test-specific entities in a single file) or a directory denoting the root of an
.idl file tree (in which case *_add_idlfiles calls specify the entites to
include in the resulting .idl file).  (In the first case, the generated .rdb
file needs to depend on that single .idl file, so the gb_UnoApiTarget ctor
contains a dependency on that additional argument, which happens, as a side
effect, to trigger rebuilds in the second, tree-based case when addition/removal
of .idl files in the tree causes updates of directory time-stamps.)

UnoApiPartTarget and all the dependency-tracking logic based on .urd files in
solenv/gbuild/UnoApiTarget.mk is gone.  Generation of an .rdb file now depends
on its source registry (see previous paragraph) and all the .idl files specified
with *_add_idlfiles (in the second, tree-based case above).

A consequence of that is that gb_UnoApi_add_idlfile, -_nohdl, and -_noheader all
do the same now.  I left them in for now anyway, maybe they become relevant
again when the use of cppumaker is changed to read directly from a source-format
registry instead of going via a .rdb registry.

The legacy tools idlc, regcompare, regmerge, and regview are still contained in
the URE or SDK for now.

cb344cd59e1ddb7c6db66dbd9263b4755969d4ba "Revert 'Looks like idlc resolved
typedefs inside sequence<...>'" is re-reverted as now "the current offapi.rdb is
generated via unoidl-write instead of idlc."

Change-Id: I3d9d92f17326bc9f49dd934c85aab6a17951d06d

1 files changed, 6 insertions, 9 deletions

diff --git a/unoidl/README b/unoidl/README
index 7ec26a0bbdfa..34e1cde6fef9 100644
--- a/unoidl/README
+++ b/unoidl/README
@@ -18,15 +18,12 @@ files.)  unoidl::loadProvider transparently detects the registry format for a
 given URI and instantiates the corresponding provider implementation.
 
 Executable_unoidl-write is a helper tool to convert from any of the registry
-formats to the UNOIDL format.  It is currently used at build-time.  idlc still
-generates the old format, and any new-format files (used at build-time only, or
-included in installation sets in URE or program/types/ or as part of bundled
-extensions that are created during the build and not merely included as pre-
-built .oxt files) are explicitly generated via unoidl-write.  The SDK is still
-designed to generate old-format files exclusively (especially, any non-bundled
-extensions will only contain old-format files for now; that allows to modify the
-new format further without having to worry about compatibility with multiple
-versions of that format).
+formats to the UNOIDL format.  It is used at build-time to compile UNOIDL format
+.rdb files (that are used at build-time only, or included in installation sets
+in URE or program/types/ or as part of bundled extensions that are created
+during the build and not merely included as pre-built .oxt files) from source
+.idl files.  (The SDK still uses idlc and generates legacy format .rdb files for
+now.)
 
 Executable_unoidl-read is a helper tool to convert from any of the registry
 formats to the source-file format.  It can be used manually after a LibreOffice