0c4c84a14b
…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> |
||
---|---|---|
.. | ||
qa/unoidl-check | ||
source | ||
CustomTarget_unoidl-check_test.mk | ||
CustomTarget_unoidl-write_test.mk | ||
Executable_unoidl-check.mk | ||
Executable_unoidl-read.mk | ||
Executable_unoidl-write.mk | ||
IwyuFilter_unoidl.yaml | ||
Library_unoidl.mk | ||
Makefile | ||
Module_unoidl.mk | ||
README.md |
Support for UNOIDL Registry Formats
Library_unoidl
contains the unoidl::Manager
and unoidl::Provider
implementations
for the following registry formats:
- The new
UNOIDL
binarytypes.rdb
format. - The old legacy binary
types.rdb
format (based on modules "store" and "registry"). - A source-file format, reading (multiple)
UNOIDL
entity definitions directly from a single.idl
source file. - A source-tree format, reading
UNOIDL
entity definitions directly from a tree of.idl
source files rooted at a given directory. (Where an entity namedfoo.bar.Baz
is expected in a file namedfoo/bar/Baz.idl
within that tree.)
(While .idl
files still contain #include
directives for legacy idlc, the source-
based formats ignore any preprocessing directives starting with #
in the .idl
files.) unoidl::Manager::addProvider
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 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.
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
version update to create new reference registries for Executable_unoidl-check
.
Executable_unoidl-check
is a helper tool to check that one registry is
backwards-compatible with another registry. It is used at build-time to detect
inadvertent breakage of the udkapi and offapi APIs.
Specification of the New UNOIDL types.rdb Format
The format uses byte-oriented, platform-independent, binary files. Larger quantities are stored LSB first, without alignment requirements. Offsets are 32 bit, effectively limiting the overall file size to 4GB, but that is not considered a limitation in practice (and avoids unnecessary bloat compared to 64 bit offsets).
Annotations can be added for (non-module) entities and certain parts of such
entities (e.g., both for an interface type definition and for a direct method of
an interface type definition; the idea is that it can be added for direct parts
that forma a "many-to-one" relationship; there is a tradeoff between generality
of concept and size of representation, esp. for the C++ representation types in
namespace unoidl
) and consist of arbitrary sequences of name/value strings.
Each name/value string is encoded as a single UTF-8 string containing a name (an
arbitrary sequence of Unicode code points not containing U+003D EQUALS SIGN
),
optionally followed by U+003D EQUALS SIGN
and a value (an arbitrary sequence of
Unicode code points). The only annotation name currently in use is "deprecated"
(without a value).
The following definitions are used throughout:
UInt16
: 2-byte value, LSB firstUInt32
: 4-byte value, LSB firstUInt64
: 8-byte value, LSB first- Offset:
UInt32
value, counting bytes from start of file NUL
-Name: zero or more non-NUL
US-ASCII bytes followed by aNUL
byte- Len-String: UInt32 number of characters, with
0x80000000
bit 0, followed by that many US-ASCII (forUNOIDL
related names) resp. UTF-8 (for annotations) bytes - Idx-String: either an Offset (with
0x80000000
bit 1) of a Len-String, or a Len-String - Annotations:
UInt32
numberN
of annotations followed byN * Idx-String
- Entry: Offset of
NUL
-Name followed by Offset of payload - Map: zero or more Entries
The file starts with an 8 byte header, followed by information about the root
map (unoidl-write
generates files in a single depth-first pass, so the root map
itself is at the end of the file):
- 7 byte magic header
UNOIDL\xFF
- version byte 0
- Offset of root Map
UInt32
number of entries of root Map ...
Files generated by unoidl-write follow that by a
"\0** Created by LibreOffice " LIBO_VERSION_DOTTED " unoidl-write **\0"
banner (cf. config_host/config_version.h.in
), as a debugging aid. (Old versions
used reg2unoidl
instead of unoidl-write
in that banner.)
Layout of per-entry payload in the root or a module Map:
-
kind byte:
-
0: module
- followed by:
UInt32
numberN1
of entries of MapN1 * Entry
- followed by:
-
otherwise:
-
0x80
bit: 1 if published -
0x40
bit: 1 if annotated -
0x20
bit: flag (may only be 1 for certain kinds, see below) -
remaining bits:
-
1: enum type
- followed by:
UInt32
number N1 of membersN1 * tuple
of:Idx-String
UInt32
- if annotated: Annotations
- followed by:
-
2: plain struct type (with base if flag is 1)
- followed by:
- if "with base":
Idx-String
UInt32
numberN1
of direct membersN1 * tuple
of:Idx-String
nameIdx-String
type- if annotated: Annotations
- if "with base":
- followed by:
-
3: polymorphic struct type template
- followed by:
UInt32
numberN1
of type parametersN1 * Idx-String
UInt32
numberN2
of membersN2 * tuple
of:- kind byte:
0x01
bit is 1 if parameterized type Idx-String
nameIdx-String
type- if annotated: Annotations
- kind byte:
- followed by:
-
4: exception type (with base if flag is 1)
- followed by:
- if "with base":
Idx-String
UInt32
numberN1
of direct membersN1 * tuple
of:Idx-String
nameIdx-String
type- if annotated: Annotations
- if "with base":
- followed by:
-
5: interface type
- followed by:
UInt32
numberN1
of direct mandatory basesN1 * tuple
of:Idx-String
- if annotated: Annotations
UInt32
numberN2
of direct optional basesN2 * tuple
of:Idx-String
- if annotated: Annotations
UInt32
numberN3
of direct attributesN3 * tuple
of:- kind byte:
0x02
bit: 1 if read-only0x01
bit: 1 if bound
Idx-String
nameIdx-String
typeUInt32
numberN4
of get exceptionsN4 * Idx-String
UInt32
numberN5
of set exceptionsN5 * Idx-String
- if annotated: Annotations
- kind byte:
UInt32
numberN6
of direct methodsN6 * tuple
of:Idx-String
nameIdx-String
return typeUInt32
numberN7
of parametersN7 * tuple
of:- direction byte: 0 for in, 1 for out, 2 for in-out
Idx-String
nameIdx-String
type
UInt32
numberN8
of exceptions- N8 * Idx-String
- if annotated: Annotations
- followed by:
-
6: typedef
- followed by:
Idx-String
- followed by:
-
7: constant group
- followed by:
UInt32
numberN1
of entries of MapN1 * Entry
- followed by:
-
8: single-interface--based service (with default constructor if flag is 1)
- followed by:
Idx-String
- if not "with default constructor":
UInt32
numberN1
of constructorsN1 * tuple
of:Idx-String
UInt32
numberN2
of parametersN2 * tuple
of- kind byte:
0x04
bit is 1 if rest parameter Idx-String
nameIdx-String
type
- kind byte:
UInt32
numberN3
of exceptionsN3 * Idx-String
- if annotated: Annotations
- followed by:
-
9: accumulation-based service
- followed by:
UInt32
numberN1
of direct mandatory base servicesN1 * tuple
of:Idx-String
- if annotated: Annotations
UInt32
numberN2
of direct optional base servicesN2 * tuple
of:Idx-String
- if annotated: Annotations
UInt32
numberN3
of direct mandatory base interfacesN3 * tuple
of:Idx-String
- if annotated: Annotations
UInt32
numberN4
of direct optional base interfacesN4 * tuple
of:Idx-String
- if annotated: Annotations
UInt32
numberN5
of direct propertiesN5 * tuple
of:UInt16
kind:0x0100
bit: 1 if optional0x0080
bit: 1 if removable0x0040
bit: 1 if maybedefault0x0020
bit: 1 if maybeambiguous0x0010
bit: 1 if readonly0x0008
bit: 1 if transient0x0004
bit: 1 if constrained0x0002
bit: 1 if bound0x0001
bit: 1 if maybevoidIdx-String
nameIdx-String
type- if annotated: Annotations
- followed by:
-
10: interface-based singleton
- followed by:
Idx-String
-
11: service-based singleton
- followed by:
Idx-String
- followed by:
-
-
if annotated, followed by: Annotations
-
-
Layout of per-entry payload in a constant group Map:
-
kind byte:
-
0x80
bit: 1 if annotated -
remaining bits:
-
0:
BOOLEAN
- followed by value byte, 0 represents false, 1 represents true
-
1:
BYTE
- followed by value byte, representing values with two's complement
-
2:
SHORT
- followed by
UInt16
value, representing values with two's complement
- followed by
-
3:
UNSIGNED SHORT
- followed by
UInt16
value
- followed by
-
4:
LONG
- followed by
UInt32
value, representing values with two's complement
- followed by
-
5:
UNSIGNED LONG
- followed by
UInt32
value
- followed by
-
6:
HYPER
- followed by
UInt64
value, representing values with two's complement
- followed by
-
7:
UNSIGNED HYPER
- followed by
UInt64
value
- followed by
-
8:
FLOAT
- followed by 4-byte value, representing values in ISO 60599 binary32 format, LSB first
-
9:
DOUBLE
- followed by 8-byte value, representing values in ISO 60599 binary64 format, LSB first
-
-
-
if annotated, followed by: Annotations