[M3devel] [M3commit] CVS Update: cm3

[Jay]

There is never any need to run cvtres.
I have never seen anyone do this.
You just pass the .res file to the linker and it works.
I would turn things around and ask why it was written this way in the first place, different than all other systems?
 
 
I can imagine one very marginal very minor point.
If the .res file is linked into multiple executables, there might be microscropic build perf win in running cvtres once.
 
 
I would like further simplification here but I didn't do the research needed.
In particular, I don't think clients should have to say if equal (TARGET, "WIN32").
The Quake code already does that, but you'd have to make sure the package is shipped for all platforms so they have the .tmpl file.
 
 
 - Jay


_______________________________
> Date: Sun, 25 Jan 2009 19:43:27 -0500
> From: rcoleburn at scires.com
> To: jkrell at elego.de; m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> Jay:
>
>
>
> Please explain what you are doing here. I don't want to break stuff just to make extremely old and no longer supported toolsets work.
>
>
>
> My recollection is that the cvtres program is used in getting icon resources et al added to the executable. I know that the CM3IDE package is dependent on the WindowsResources package as are a lot of my programs. If you make changes here, we need to make sure it doesn't break existing stuff.
>
>
>
> Also, if there is a better way to go about it, I don't mind learning, but we will need to deal with making everything that depends on windowsResources continue to work.
>
>
>
> Regards,
>
> Randy
>
>>>> Jay Krell 1/25/2009 5:36 PM>>>
> CVSROOT:/usr/cvs
> Changes by:jkrell at birch.09/01/25 17:36:15
>
> Modified files:
> cm3/m3-sys/windowsResources/src/: winRes.tmpl
>
> Log message:
> Surely there is no need to run cvtres manually.
> Not doing so works with a few toolsets I have tried.
> The linker accepts .res files and it is normal to give them to it.
> The invocation here is incompatible with very old toolsets (Visual C++ 2.0)
> and a minor porting nuisance due to the use of /machine:x86.
> The only savings I can imagine is if some resources are used "like a library"
> and linked into multiple binaries, that invocations of cvtres can be reduced,
> from once per link to just once.
>
>