Re: [patch #3946] Add make support for windows PE resources

[Nicola Pero]

> > Thanks -- it's a good one.  We've just added something really similar to
> > gnustep-make HEAD -- the only real difference with this patch is that the
> > variable is called xxx_WINDRES_FILES instead of xxx_RC_FILES.
>
> The reason I didn't do that is RC_FILE has an implied meaning in Unix which I 
> felt could confuse things.

OK - I don't follow you - I suspect you got confused - why did you call 
the variable xxx_RC_FILES then ?

Anyway, you don't need to reply to this (let's avoid silly flame threads) 
and the only important thing is that it looks like you agree 
xxx_WINDRES_FILES is better than xxx_RC_FILES, so the current gnustep-make 
CVS (where I used xxx_WINDRES_FILES) is OK. :-)


> > Also, on CVS we only add those rules for mingw32.  Maybe we should always 
> > have
> > them like in this patch ?  Problem is, windres is not available on (eg)
> > GNU/Linux.  So the idea is that you'd have a xxx_WINDRES_FILES and they 
> > would
> > be compiled in but only on Windows (presumably in some cases you have
> > resources that you want to compile in only on windows ?)
>
> Windres is open source and supports elf targets so you can use it on Linux. 
> Beside which I thought it cleaner to have unconditional support and allow the 
> GNUmakefile to control things. I like leaving decisions in the hands of the 
> programmer.

Ahm ... OK, good point and no big deal -- we can change it ... but ... but 
windres is not installed on my (fairly comprehensive) GNU/Linux ... so I 
guess it's not installed on most machines except for Windows.

I thought the only reason to use windres when programming with GNUstep was 
to have an application icon (and other Windows-specific resources) 
compiled into your app. :-)

Else, why using a non-portable Windows-specific way of adding resources to 
your program ?  Normally you can just bundle the resources into the 
application bundle (much easier and nicer and more portable than a 
WINDRES_FILES). ;-)

So my idea is that you would specify xxx_WINDRES_FILES = yyy.rc mostly to 
include in your application Windows-specific resources (such as the 
Windows icon) that make sense only on Windows.  And then the most logical 
thing for the gnustep-make system to do is to ignore the Windows-specific 
resources on other platforms, and compile them in on Windows.

I suppose I could remove the conditionals, but that seems to imply that 
every GNUmakefile adding a Windows icon to the application will be 
clobbered with conditionals ... (no big deal though!)

I can't think of any case where you want a windres file to use on all 
platforms.  That would cause your program not to compile on Linux or Apple 
(unless, presumably, you went throught the pain of downloading a version 
of windres working on your platform, and installed it).  And you 
could/should bundle your resources using the standard OpenStep .app bundle 
methods that work reliably on all platforms!

So I would leave it as it is, maybe enable it on Cygwin as well rather 
than just Mingw ?

Or maybe as you say we'll just enable it anywhere and leave to the 
GNUmakefile author the trouble of conditionaliting things ... it might be 
easier to understand the GNUmakefile if you see clearly the conditionals 
spelt out in the GNUmakefile itself.  Actually I don't mind doing this and 
removing the conditionals from gnustep-make, it might make writing a 
Windows GNUmakefile a bit more complicated, but the result might also be a 
bit more readable. :-)

Maybe someone else has got a different angle that we've not considered ?

Btw, I might have misunderstood the usage of .rc/windres files entirely 
... to me it looked like the Windows icon was the main driver behind them.



> > Another comment is that in this patch you have $(RCFLAGS) ... maybe we need
> > something like that ?  Any example of flags that someone might want to pass 
> > to windres ?
>
> We need something like that. Consider:
>
> Usage: windres [option(s)] [input-file] [output-file]
> The options are:
>  -i --input=<file>            Name input file
>  -o --output=<file>           Name output file
>  -J --input-format=<format>   Specify input format
>  -O --output-format=<format>  Specify output format
>  -F --target=<target>         Specify COFF target
>     --preprocessor=<program>  Program to use to preprocess rc file
>  -I --include-dir=<dir>       Include directory when preprocessing rc file
>  -D --define <sym>[=<val>]    Define SYM when preprocessing rc file
>  -U --undefine <sym>          Undefine SYM when preprocessing rc file
>  -v --verbose                 Verbose - tells you what it's doing
>  -l --language=<val>          Set language when reading rc file
>     --use-temp-file           Use a temporary file instead of popen to read
>                               the preprocessor output
>     --no-use-temp-file        Use popen (default)
>  -r                           Ignored for compatibility with rc
>  -h --help                    Print this help message
>
> Let's see... defining symbols is frequently useful. Being verbose is 
> generally helpful when things are going wrong. I've needed to specify 
> non-default targets at times in the past. I can see situations when 
> specifying an additional include directory is needed...

Thanks! -- I agree this is a good point, and it's missing in the current 
gnustep-make.  We probably need to add something like WINDRESFLAGS, 
similar to CFLAGS.  Quite simple ... I'll add it tomorrow. :-)

Thanks