[Development] RCC XML and options

[André Pönitz]

On Thu, Sep 04, 2014 at 01:19:52PM +0000, John M. Dlugosz wrote:
> I read the documentation on the Resource Compiler (rcc), and my interest
> is in building existing projects using standard platform tools without
> qmake.

[Out of curiosity, what are the "standard platform tools" in this case?]

> That is, I’m adding logic to run rcc over a *.qrc file to produce
> a cpp file.
> 
> First, I read about the -compress / -no-compress options. That is all or
> nothing for the entire translation unit. Is there an attribute in the XML
> (qrc) file to control this on a case-by-case basis?

No, and that's intentional. The uncompression is done once for the whole
data set (or not at all). That's faster and more compact then compressing
files one-by-one.

> In particular, it’s counterproductive to try and compress a png file, but
> other kinds of resources might very well benefit from compression, and
> differing level for each.

Right. If you have such a case you can split your resources into 
two .qrc files and compress one, but not the other.

> I could not find any additional documentation on the qrc xml file format,
> and only see the alias attribute. Are there others, such as compression?

No, the format is really that simple.

> (Aside: what about different compression libraries? 7zip’s lzma appears
> to produce much smaller files than classic deflate.)

Such features comes at a price, e.g. run time, and code complexity.
(Runtime-wise it's actually often faster to not compress at all)

If you have a case where another compression algorithm would *really* make
a difference you can always compress yourself using your favourite
algorithm and then use rcc without compression.
 
> The second issue concerns the -name option to rcc. Using a build tool as
> mentioned above, every *.qrc file needs to have its -name associated
> somehow. That would mean manually listing every such file individually
> and repeating the command with different parameters.

The canonical solution is to use different base names for different .qrc
files, and have e.g. Makefile rules like

%.cpp: %.qrc
    rcc -name $* -o $@ $<

(or leave out the -name altogether in that case, or use a build system
that sets up these rules for you).

> That is in contrast
> to a rule that says “every *.qrc file produces a *.cpp file with a name
> derived from the input file”. It is not great to determine the -name from
> the input file too,

I don't see much difference in "making sure that different .qrc files have
different 'name' attributes somewhere inside" vs "make sure that .qrc files
have different base names" vs "make sure that different -name options are
passed at rcc time".

> as every subproject will want to have a file named
> simply resources.qrc and not some globally unique name.

You could be equally well establish a policy for your project that each
subproject has a file called <subproject>.qrc.

> It would make sense to put the -name in the qrc file itself, rather than
> supplied separately to the rcc tool. This could simply be another
> attribute to the qresource element that serves the same function as the
> existing -name option.

That should be doable, even if I currently doubt it'd be worthwhile.

Usually there are three approaches to get such things done:
  (1) file a festure request on bugreports.qt-project.org
      and hope someone implements it,
  (2) ask your Support contact to get this done for you,
  (3) contribute a patch via codereview.qt-projects.org.

(Realistically, (1) is unrealistic in this particular case)

> More extensible would be a new element that could
> contain more details for the generated code.

That's less likely to happen, but at least in theory there are the same
three routes open.

> Let me make sure I understand what that’s used for: The named function
> needs to be called at some point to make the resources available, but is
> otherwise not used, right? Different *.qrc files prepared by different
> developers in different parts of the code base (in the same resulting
> executable file) are distinguished by the ‘prefix’, right?
> 
> If that’s right, couldn’t the generated code contain a dummy object using
> the “static constructor” technique to cause the registration function to
> be called sometime before main(), and not need an exposed name at all?

That's already happening. Of course, the "static constructor" must be
triggered _somehow_, e.g. from the dynamic loader.

> (Update:  it looks like a macro is generating a static object with a
> ctor, but it is still necessary to explicitly call the init function for
> it to work.

Did you try and it didn't work without explicitly calling the setup
function? How did you build that application?

Andre'