Re: [jamboost] Re: Re: resource files support

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-05 01:06:17

Hi Martin

> > 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 ;

I see. I hope that in case of typelib the dependency scanning will be rather 
simple.

> > > The type library compiler can also generate a few more files, like c
>
> source
>
> > > files and headers, which contain the "marshalling code". 
> > 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

That's good.

>
> [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.

Thanks, but I think there's no need now. When/if we get to supporting ILD 
compiler we can come back to this topic.

> > > *.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 ;

Thanks, I understand the picture. I'm guess we'd still need to extract the set 
of languages somehow (e.g. to support "clean"). Hmm... GNU gettext is a bit 
simpler ;-)

> 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.

If they span several lines, we're out of luck -- since Jam scans file 
line-by-line. In other cases, I think we can handle it.

> > 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 "" ?

Might be. Need to check it out.

Thanks,
Volodya