From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-04 05:54:43
> Hi Vladimir,
> > Can you tell more about it? What's type libraries and how/why one would
> > need to integrate it in rc file?
> Type libraries are used in the context of COM to make public the interface
> definition of a Active X component. So other programs can use this
> description to call remote functions in a program or DLL.
> You can read here what MS explains about type libraries in the MSDN:
> 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?
> *.idl is the Interface Description [Language] file.
> It is compiled by the IDL compiler "midl".
> *.tlb is a the resulting binary file, which is then integrated into the
> resource table of the DLL.
> 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.
> 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
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?
> 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?
> Of course it would be nice, if all this could be done by boost build
> automaticly. I did get it working, but I had a bit difficulties to find all
> those "object-name", "UserObject", ... which I had to modify.
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
> Another little question:
> I tried to use an expression like this:
> If $(SOURCE_GRIST) is an empty string, the result is also empty, regardles
> of the contents of $(<) ! Is this the correct behaviour? I explected to get
> just the new filename without any grist.
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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk