glib/docs/reference/gio/glib-compile-resources.xml
Emmanuele Bassi 7bc6ef8734 Do not generate C resources for all possible toolchains
The resources data is generated for both GCC and MSVC toolchains, even
though we know beforehand which toolchain we're going to compile it for.
By dropping the data duplication we make the generated resources file
faster to compile, especially when dealing with large embedded data,
instead of relying on the C pre-processor to walk the whole file and
discard the branch we're not using.
2022-02-14 13:09:22 +00:00

255 lines
8.5 KiB
XML

<refentry id="glib-compile-resources" lang="en">
<refentryinfo>
<title>glib-compile-schemas</title>
<productname>GIO</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Alexander</firstname>
<surname>Larsson</surname>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>glib-compile-resources</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>glib-compile-resources</refname>
<refpurpose>GLib resource compiler</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>glib-compile-resources</command>
<arg choice="opt" rep="repeat">OPTION</arg>
<arg choice="req">FILE</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1><title>Description</title>
<para><command>glib-compile-resources</command> reads the resource description from
<replaceable>FILE</replaceable> and the files that it references
and creates a binary resource bundle that is suitable for use with the
<link linkend="GResource"><type>GResource</type></link> API.
The resulting bundle is then written out as-is, or as C source for linking into
an application.
</para>
<para>
The XML resource files normally have the filename extension <filename>.gresource.xml</filename>.
For a detailed description of the XML file format, see the
<link linkend="GResource"><type>GResource</type></link> documentation.
</para>
</refsect1>
<refsect1><title>Options</title>
<variablelist>
<varlistentry>
<term><option>-h</option>, <option>--help</option></term>
<listitem><para>
Print help and exit
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--version</option></term>
<listitem><para>
Print program version and exit
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--target=<replaceable>TARGET</replaceable></option></term>
<listitem><para>
Store the compiled resources in the file <replaceable>TARGET</replaceable>.
If not specified a filename based on the <replaceable>FILE</replaceable>
basename is used.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--sourcedir=<replaceable>DIRECTORY</replaceable></option></term>
<listitem><para>
The files referenced in <replaceable>FILE</replaceable> are loaded from
this directory. If not specified, the current directory is used.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--generate</option></term>
<listitem><para>
Write the output file in the format selected for by its filename extension:
<variablelist>
<varlistentry>
<term><literal>.c</literal></term>
<listitem><para>C source</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>.h</literal></term>
<listitem><para>C header</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>.gresource</literal></term>
<listitem><para>resource bundle</para></listitem>
</varlistentry>
</variablelist>
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--generate-source</option></term>
<listitem><para>
Instead of a writing the resource bundle in binary form create a C source file
that contains the resource bundle. This can then be compiled into an
application for easy access.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--generate-header</option></term>
<listitem><para>
Generate a header file for use with C code generated by
<option>--generate-source</option>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--generate-dependencies</option></term>
<listitem><para>
Prints the list of files that the resource bundle references to standard output.
This can be used to track dependencies in the build system. For example, the
following make rule would mark <replaceable>test.gresource</replaceable> as
depending on all the files that <replaceable>test.gresource.xml</replaceable>
includes, so that is is automatically rebuilt if any of them change:
<programlisting>
test.gresource: test.gresource.xml $(shell $(GLIB_COMPILE_RESOURCES) --generate-dependencies test.gresource.xml)
</programlisting>
Note that this may or may not be portable to non-GNU <command>make</command>.
</para>
<para>
Also see <option>--dependency-file</option>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--c-name</option></term>
<listitem><para>
Specify the prefix used for the C identifiers in the code generated by
<option>--generate-source</option> and <option>--generate-header</option>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--manual-register</option></term>
<listitem><para>
By default code generated by <option>--generate-source</option> uses automatic
initialization of the resource. This works on most systems by using the
compiler support for constructors. However, some (uncommon) compilers may not
support this, you can then specify <option>--manual-register</option>,
which will generate custom register and unregister functions that your code
can manually call at initialization and uninitialization time.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--internal</option></term>
<listitem><para>
By default code generated by <option>--generate-source</option> declares all
initialization functions as <type>extern</type>. So they are exported
unless this is prevented by a link script or other means. Since libraries
usually want to use the functions only internally it can be more useful to
declare them as
<link linkend="G-GNUC-INTERNAL:CAPS"><literal>G_GNUC_INTERNAL</literal></link>
which is what <option>--internal</option> does.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--external-data</option></term>
<listitem><para>
By default code generated by <option>--generate-source</option> embeds the
resource data as a string literal. When <option>--external-data</option>
is given, the data is only declared in the generated C file, and the data
has to be linked externally.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--dependency-file=<replaceable>FILE</replaceable></option></term>
<listitem><para>
Write dependencies in the same style as gcc -M -MF to the given file.
If <option>FILE</option> is -, the dependencies are written to the standard
output. Unlike <option>--generate-dependencies</option>, this option can be
combined with other <option>--generate</option> options to generate dependencies
as a side-effect of generating sources.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--generate-phony-targets</option></term>
<listitem><para>
When creating a dependency file with <option>--dependency-file</option>
include phony targets in the same style as gcc -MP. This would typically
be used with <literal>make</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--compiler=<replaceable>NAME</replaceable></option></term>
<listitem><para>
Generate code that is going to target the given compiler <replaceable>NAME</replaceable>.
The current two compiler modes are "gcc", for all GCC-compatible toolchains; and "msvc",
for the Microsoft Visual C Compiler. If this option isn't set, then the default will be
taken from the <envar>CC</envar> environment variable.
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1><title>Environment</title>
<variablelist>
<varlistentry>
<term><envar>XMLLINT</envar></term>
<listitem><para>
The full path to the <command>xmllint</command> executable. This is used to
preprocess resources with the <literal>xml-stripblanks</literal> preprocessing
option. If this environment variable is not set, <command>xmllint</command> is
searched for in the <envar>PATH</envar>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><envar>GDK_PIXBUF_PIXDATA</envar></term>
<listitem><para>
Deprecated since gdk-pixbuf 2.32, as <type>GResource</type> supports embedding
modern image formats without conversion.
</para><para>
The full path to the <command>gdk-pixbuf-pixdata</command> executable. This is
used to preprocess resources with the <literal>to-pixdata</literal> preprocessing
option. If this environment variable is not set, <command>gdk-pixbuf-pixdata</command>
is searched for in the <envar>PATH</envar>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><envar>JSON_GLIB_FORMAT</envar></term>
<listitem><para>
The full path to the <command>json-glib-format</command> executable. This is used
to preprocess resources with the <literal>json-stripblanks</literal> preprocessing
option. If this environment variable is not set, <command>json-glib-format</command>
is searched for in the <envar>PATH</envar>.
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>