The
UNO tools

Usage:

The idl compiler transforms interface definitions written in idl into
urd files. The urd files are then merged into the type library
(rdb). You can find a syntax description for IDL here.

unoidl [flag | file]*

Legal flags:

-E

runs preprocessor
only, prints on stdout

-D<name>

defines macro for
the preprocessor

-OH<dir>

produce output
files in dir (pathname)

-I<dir>

includes dir in
search path for preprocessor

-V

prints version
info then exits

-Wb,arg1,argn

passes args to
BE

-B<backend>

use backend for
code generation

supported backend
is 'urd' for Uno Reflection Data.

This option is optional because default is using 'urd' backend.

-Mdepend[=match]

generate dependencies
for all generated files, to stdout. Files beginning with 'match' are
not used for dependencies. No dependencies for the doc backend.

-h

prints this usage
message and exits

-v

traces compilation
stages

-w

suppresses IDL compiler warning messages

idlc

Usage:

'idlc' is a new idl compiler. We made some changes in the IDL language
specification to simplify the syntax.

The idl compiler transforms interface definitions, written in idl, into
urd files. The urd files are then merged into the type library
(rdb). You can find a syntax description for IDL here.

idlc [-options] file_1 ... file_n | @<filename>

file_1 ... file_n

specifies one or more idl files.
Only files with the extension '.idl' are valid.

@<filename>

filename specifies the name of a command file.

Options:

-O<path>

path describes the output directory.
The generated output is a registry file with the same name as the idl input file.

-I<path>

path specifies
a directory where include files are located, that will be searched by the preprocessor.
Multiple directories can be combined with ';'.

-D<name>

name defines a
macro for the preprocessor.

-C

generate complete
type information, including additional service information and documentation.

-h|?

print this help message and exit.

cppumaker

Usage:

The cppumaker generates a C++ representation for idl types. The cppumaker
works on a typelibrary which is generated by the unoidl. It generates
the output for all specified types and for all types the specified types
depends on.

cppumaker [-options] file_1 ... file_n

Options:

-O<path>

path describes
the root directory for the generated output. The output directory
tree is generated under this directory.

-T<name>

name specifies
a type or a list of types. The output for this [t1;...] type is generated.
If no '-T' option is specified, then output for all types is generated.

-B<name>

name specifies the base node. All types
are searched under this node. Default is the root '/' of the registry
files.

-L|-C

In general, the cppumaker tool generates
getCppuType() functions in three ways:

no option (default)
This generates headers so that UNO runs correctly as long
as:

-- no scripting
is needed (in general, this needs full type description support)

-L (_ONLY_ usable on Windows!)
This option generates the shortest getCppuType() functions, but
needs a running type description manager (+provider) reading all
type information from the applicat.rdb! ==> !! Cannot be used
at setup startup, because no applicat.rdb is involved at this
early stage!!

-C (fully comprehensive type information)
This options generates the longest form of getCppuType() functions,
including a comprehensive description of a type, thus there is
no need for a type description manager (+provider) reading types
from applicat.rdb:

-- limitation:
only previously used types are provided by the runtime (i.e.,
only types which were previously registered due to a getCppuType()
call are accessible by name)

So, please keep these limitations in mind if you are not sure that
there is a running type description manager (+provider) reading from
applicat.rdb.

-G

generate only target files which do
not exist.

-Gc

generate only target files whose content
will be changed.

cunomaker

Usage:

The cunomaker generates a C representation for idl types. The cunomaker
works on a typelibrary which is generated by the unoidl. It generates
the output for all specified types and for all types the specified types
depends on.

cunomaker [-options] file_1 ... file_n

Options::

-O<path>

path describes
the root directory for the generated output. The output directory
tree is generated under this directory.

-T<name>

name specifies
a type or a list of types. The output for this [t1;...] type is generated.
If no '-T' option is specified, then output for all types is generated.

-B<name>

name specifies the base node. All types
are searched under this node. Default is the root '/' of the registry
files.

-U activate the generating of a getCppuType function

-C

In general, the cunomaker tool generates
getCppuType_<name>() functions in two ways:

no option (default)
This generates headers so that UNO runs correctly as long
as:

-- no scripting
is needed (in general, this needs full type description support)

-C (fully comprehensive type information)
This options generates the longest form of getCppuType_<name>()
functions, including a comprehensive description of a type, thus
there is no need for a type description manager (+provider) reading
types from applicat.rdb:

-- limitation:
only previously used types are provided by the runtime (i.e.,
only types which were previously registered due to a getCppuType()
call are accessible by name)

So, please keep these limitations in mind if you are not sure that
there is a running type description manager (+provider) reading from
applicat.rdb.

-G

generate only target files which do
not exist.

-Gc

generates only target files whose content
will be changed.

javamaker

Usage:

The javamaker generates the appropriate java file for each idl type.
The javamaker works on a typelibrary which is generated by the unoidl.
It generates the output for all specified types and for all types the
specified types depends on.

javamaker [-options] file_1 ... file_n

Options:

-O<path>

path describes
the root directory for the generated output. The output directory
tree is generated under this directory.

-T<name>

name specifies
a type or a list of types. The output for this [t1;...] type is generated.
If no '-T' option is specified, then output for all types is generated.

-B<name>

name specifies the
base node. All types are searched under this node. Default is the
root '/' of the registry files.

rdbmaker

Usage:

The rdbmaker generates subsets of the typelibrary. The rdbmaker works
on a typelibrary which is generated by the unoidl. It generates a subset
of the typelibrary which contains all specified types and all types the
specified types depends on. This could be used to provide all types and
only the necessary types for a component.

rdbmaker [-options] file_1 ... file_n

Options:

-O<fileName>

filename specifies
the name of the generated registry or text file.

-L

specifies that
only a text file is generated with the names of the specified types
and their dependencies. Default is that a registry file will be created.

-T<name>

name specifies
a type or a list of types. The output for this [t1;...] type is generated.
If no '-T' option is specified, then output for all types is generated.

-FT<name>

name specifies
a type or a list of types. For these types, nothing will be generated.

-F<file>

file specifies
a text file. For the specified types in this file, nothing will be
generated.

-B<name>

name specifies the
base node. All types are searched under this node. Default is the
root '/' of the registry files.

regcomp

Usage:

Regcomp is a tool to register|revoke external UNO components into|from
a registry which is used for an UNO environment.

-br registryfile = the name of the registry used for bootstrapping
the program. If the bootstrap registry is specified and has the same
name as the registration registry, the -r option is optional.

-r registryfile = the name of the registry (will be created if it does not
exist) where the component should be registered.

-c locationUrls = the location of an component (DLL, Class name, or
an url of a jar file) or a list of urls separated by ';'s. Note, if a
list of urls is specified, the components must all need the same loader.

-l componentLoaderUrl = the name of the needed loader, if no loader
is specified the 'com.sun.star.loader.SharedLibrary' is used. loaders:
com.sun.star.loader.SharedLibrary | com.sun.star.loader.Java.

regmerge

Usage:

Regmerge is a small tool to merge different registry files under a specified
key into another registry file. If a value already exists in the targetfile
the value would be overwritten by the value of the sourcefile.

regmerge mergefile mergeKeyName regfile_1 ... regfile_n

regmerge @regcmds

regview

Usage:

Regview is a small tool to show the content of a registry file. The
tool dumps the hierarchical structure and the values of the nodes to
stdout in a human readable form.

regview registryfile [keyName]

xml2cmp

Usage:

The tool xml2cmp.exe parses .xml files, which
contain the descriptions of components that implement UNO services. Each
.xml file refers to one library. The library may contain one or more component
descriptions.
There are two ways of using xml2cmp.exe:

xml2cmp [-func funcFile] [-html htmlFile] [-types typeFile] Xml_FileNameThis version parses the file <xml_filename> and produces
three possible
types of output, each of which is optional, but there must be at least
one of them.

Options:

-func funcFile
produces a file with the name <funcfile>. This should be .c / .cxx
/ .cpp or similar kind of source code file. This file contains the
definition of the function const sal_Char * SAL_CALL component_getDescriptionFunc();
which returns the parsed file as ASCII text.

- html htmlFile
produces a file with the name <htmlfile>. It should be a .htm / .html
file. That file contains the contents of the parsed file in HTML-readable
form.

-types typeFile
produces a textfile with the name <typefile>. This textfile is intended
to be included in a makefile and contains the definition of a variable
<libraryname>
<libraryName>_XML2CMPTYPES=
<type_used_by_LibraryName_1> \
<type_used_by_LibraryName_2> \
...

So, the variable <libraryName>_XML2CMPTYPES contains
a list of the types, used by that library.

All output of this first version of xml2cmp is put into the working directory.

xml2cmp -ix <sourcedirectory> <outputdirectory>
[<tagname1> [ <tagname2> ...]] This version parses all .xml files which are found in <sourcedirectory>
or its subdirectories. It produces the .html output of all parsed .xml
files (as in version 1 above). Also, it produces a file, named xmlindex.html.
This is an HTML file which contains tables alphabetically ordered on
the left side, which allows assigning, from one XML-tags' contents to another
(of all original parsed .xml files). The following tables are produced
("Module" refers to a library):

The starter loads the component and instantiates it. The component
must export the interface com.sun.star.lang.XMain:

interface XMain : com::sun::star::uno::XInterface
{
/** This method is called to run the component.
<BR>
@param aArguments command
line arguments
@return process error
code to be returned to system
*/
long run( [in] sequence< string > arguments
);
};

Method run() will be called and returns the error code given,
back to the system. If the uno starter is executed with the -u
(URL) option, then XInitialization is used instead of XMain. The
-u option is described later.

You can either specify a component implementation name and a
component location url (e.g., a shared library or jar file) or
you specify the service name of a registered service.

ComponentImplementationNameComponentImplementationName is the implementation name
of the component, e.g., MyFooServiceImpl.

LocationUrlLocationUrl is the file name of a shared library or jar
file.

ServiceName
You can also specify a ServiceName if your component
is already registered. This looks for any registered component
implementation in the registry.

RegistriesThe optional Registries (e.g., c:\myreg.rdb) are
used by the ServiceManager. The ro
ones are opened for reading only; whereas, a single rw
one will be opened for reading and writing. If the rw
one does not exist, then it may be created. Components may
read and write to store their persistent state.

The -u (URL) option provides the opportunity to accept incoming
connections and distribute component instances to other processes.
Clients resolve outer process objects using the com.sun.star.connection.UnoUrlResolver
service with this url. The starter accepts incoming client connections
of the clients' com.sun.star.connection.UrlResolver service and
provides the desired instance.
Component instances started via -u are not run using the XMain
interface, they are initialized via the XInitialization interface,
given the command line params.

HostNameSpecifying a host name might be necessary to distinguish
the network interface to be used, if a machine is part of
two networks.

PipeNameName of a named pipe.

NameIdentifier for called component instances.

--singleacceptThe uno starter will accept one connection, provide the
component instance and die.

--singleinstanceThe uno starter will accept any number of connections,
but will provide the same single component instance any time
instead of creating a new instance for each connection.

Apache and the Apache feather logo are trademarks of The Apache Software Foundation.
OpenOffice, OpenOffice.org and the seagull logo are registered trademarks of The Apache Software Foundation.
Other names appearing on the site may be trademarks of their respective owners.