[fpc-devel] Enabling use of {$R *.dfm} on Windows

[Michael Van Canneyt]

On Fri, 27 Jul 2007, Sergei Gorelkin wrote:

> Florian Klaempfl wrote:
> > Michael Van Canneyt schrieb:
> > > > I probably should support win64/gorc, too. What will be the proper way
> > > > to do
> > > > it: recognize gorc switches in the commandline, or compile a separate
> > > > executable, or whatever else? Is gorc executable available for
> > > > crosscompiling
> > > > from win32?
> > > I have no idea. I suppose it is up to you to detect whether you want to
> > > use
> > > windres or gorc, and transform the arguments if you are going to call
> > > gorc.
> > 
> > That's exactly one of the reasons why I think that it's better to move
> > the utility into the compiler.
> 
> I was thinking about this, too. For binary streams there's no visible problem
> to do this. But for text streams, it's necessary to call
> ObjectTextToResource(), and that would make compiler depend of Classes unit.
> 
> There's another point. Before revision 7515, windres was used to convert .rc
> directly into .o, therefore I designed the utility to be a windres proxy -
> just not to mess with .o format internals. But now the resources are processed
> in two steps, and the first step must write .res only - that is fairly easy.
> The utility may write .res directly and need not be a windres proxy.
> So maybe it could be better way to detect format of resource file in compiler
> and invoke either new utility or windres? (customizations introduced in r8164
> would then be unnecessary)

You must then introduce new 'helper binary' definitions in the compiler
This is what I wanted to avoid with the command-line switch in the first
place. My solution is more general, as it means no names are hardcoded in
the compiler.

Michael.