Re: Re: resource files support

From: Martin Fuchs (gclbb-jamboost_at_[hidden])
Date: 2003-06-04 16:21:34

Hi Vladimir,

> > When building my project, I'm doing something like this:
> >
> > *.idl --midl--> *.tlb --rc--> *.res --link--> *.dll
>
> I now understand. So, as far as resource compiler is concerned, it's just
> binary data which must be added to resources?

Correct.

> > The TLB is called by the *.rc file with a statement like this:
> > 1 TYPELIB "foo.tlb"
>
> Hmm... so the "*res" file shoud depend on "foo.tlb". IOW, this requires
> automatic dependency scanning for resource files.

Yes, that would be the correct solution.

By now I achieved the dependency by using an additional rule "TypeLib",
which explicitly defines the relation between dll_name.dll and foo.idl:

dll dll_name : foo.cpp foo.rc foo.idl ;
TypeLib dll_name : foo.idl ;

If there would be automatic dependency scanning, it would be enough to just
list the source code files you want to compile:

dll dll_name : foo.cpp foo.rc foo.idl ;

> > The type library compiler can also generate a few more files, like c
source
> > files and headers, which contain the "marshalling code". This should
then
> > be compiled by the C compiler and linked together with the rest of the
> > program.
>
> Are those files known statically? Or compiler decides what files to
generate
> based on content of *idl files --- e.g. one header per interface, or
> something like that?

Well, you can list the file names in the command line, which calls midl,
e.g.:
midl -nologo -app_config foo.idl -tlb foo.tlb -h foo.h -iid
foo_uuid.c -proxy foo_prxy.c -dlldata foo_data.c

[just copying the command line from the makefile]
I must permit, it's a few years ago, since I wrote the makefile. I'm not
exactly shure what the compiler does without this options. If you are
interested, I will look more into detail.

> > The other type of file, I'm using in context of resource files, are so
> > called "message files" (*.mc). This contain internationalized text
prases,
> > which can be read by the application. The message compiler "mc"
generates
> > one binary output file for any used language:
> >
> > *.mc --mc--> msg_ger.bin, msg_eng.bin --rc--> *.res --link--> *.dll
> >
> > This are integrated into the resource file by the resource compiler.
>
> Same question here. Is the set of languages defined only in "mc" file?

Yes, there is a section in the .mc file like this:

LanguageNames=(
E=0x809:msg_eng
G=0x407:msg_ger
)

One could scan for it and determine the the language file names.
But, I don't think, this is really needed. The ".BIN" files are integrated
into the ".rc" file by means of another ".rc" file. This one is generated by
the message compiler. It's name is that of the ".mc" file, just with
extension ".rc" . In the main ".rc" file there is the section to call this
generated file:

#include "foo_msg.h"
#include "foo_msg.rc"

Yes, you see another file name "foo.h". This is also an output file of mc.

So, to paint the whole picture of the example:

foo_msg.mc --mc--> msg_ger.bin, msg_eng.bin, foo_msg.rc, foo_msg.h
foo.rc --rc--> foo.res --link--> bar.dll

Here are all the dependencies:

DEPENDS msg_ger.bin, msg_eng.bin, foo_msg.rc, foo_msg.h : foo_msg.mc ;
INCLUDES foo.rc : foo_msg.rc, foo_msg.h ;
INCLUDES foo_msg.rc : msg_ger.bin, msg_eng.bin ;
DEPENDS foo.res : foo.rc ;
DEPENDS bar.dll : foo.res ;

> I hope it will be supported. My plans for the next release include support
for
> gettext (GNU i18n solution), and improved header scanning (which can
handle
> rc files).

Sounds very good. :-)
So you also want to handle things like this in resource files to build the
dependency graph?

IDI_ICON1 ICON DISCARDABLE "icon1.ico"
IDB_PICTURE BITMAP DISCARDABLE "picture.bmp"

I don't know, if regular expressions are powerfull enough to do this kind of
thing. Since the single statements could (theoretically) span more than one
line.

> I fact, even the following
>
> SG = ;
> l = foo/bar/x.s ;
> ECHO $(l:G=$(SG)) ;
> ECHO $(l:G=) ;
>
> produce different outputs from the two ECHOs. I would say it's a bug. Will
> investiage.

OK. Just a guess: eventually a problem of distinction between NULL and empty
strings "" ?

Martin

--
Martin Fuchs
martin-fuchs_at_[hidden]