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

[Sheldon Gill]

Update of patch #3946 (project gnustep):

  Status:None => Done   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Nicola Pero]

So my current inclination (totally open to discussion) is:

xxx_WINDOWS_RC_FILES for the files,
WINDRES_FLAGS for the flags to pass to the 'windres' program

Sounds reasonable ?  Any comments ?


Sounds perfectly reasonable. Perhaps shorten it to _WIN_RC?

The only issue with this solution is that the FLAGS variable is named 
rather differently to the others. As long as the docs are clear I don't 
see any problem. I have, btw, some -make docs to contribute too.


Good points! ... what about xxx_WINDOWS_RC_FILES and WINDOWS_RC_FLAGS ? 


not _FLAGS, because rc files aren't flags.


Thanks for your opinion ... what's your preference for the flags variable 
name then ?


I am somewhat indifferent... I'd say xxx_WINDOWS_RC_FILES is best, since the 
FSF "shuns" use of "WIN" to denote Windows. It's less descriptive/clear 
anyways.


Thanks ... I see your point - good point! - I agree WINDOWS is best to 
denote Windows. :-)


So we agree xxx_WINDOWS_RC_FILES is a good choice for the list of files -- 
good.


Now we need two variable names - one for the list of files, one for the 
flags used to compile the files.  Usually in gnustep-make they are named 
the same (or very similarly), as in OBJC FILES and OBJC FLAGS.  But not 
always exactly the same, for example we have JAVA FILES but JAVAC FLAGS 
and JAVAH FLAGS.


If we agree the variable name for the files is called 
xxx_WINDOWS_RC_FILES, then I was going to use xxx_WINDOWS_RC_FLAGS for the 
flags variable, to have a similar/consistent name.


Mainly so that someone who doesn't really know anything about this should 
be able to understand at a quick glance (when looking at a GNUmakefile) 
that the xxx_WINDOWS_RC_FLAGS variable is related to the 
xxx_WINDOWS_RC_FILES.


Sounds OK ?

Thanks


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Alex Perez]

Nicola Pero wrote:




So my current inclination (totally open to discussion) is:

xxx_WINDOWS_RC_FILES for the files,
WINDRES_FLAGS for the flags to pass to the 'windres' program

Sounds reasonable ?  Any comments ?



Sounds perfectly reasonable. Perhaps shorten it to _WIN_RC?

The only issue with this solution is that the FLAGS variable is 
named rather differently to the others. As long as the docs are 
clear I don't see any problem. I have, btw, some -make docs to 
contribute too.




Good points! ... what about xxx_WINDOWS_RC_FILES and WINDOWS_RC_FLAGS ? 



not _FLAGS, because rc files aren't flags.



Thanks for your opinion ... what's your preference for the flags 
variable name then ?



I am somewhat indifferent... I'd say xxx_WINDOWS_RC_FILES is best, since 
the FSF "shuns" use of "WIN" to denote Windows. It's less 
descriptive/clear anyways.



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Nicola Pero]

So my current inclination (totally open to discussion) is:

xxx_WINDOWS_RC_FILES for the files,
WINDRES_FLAGS for the flags to pass to the 'windres' program

Sounds reasonable ?  Any comments ?


Sounds perfectly reasonable. Perhaps shorten it to _WIN_RC?

The only issue with this solution is that the FLAGS variable is named 
rather differently to the others. As long as the docs are clear I don't 
see any problem. I have, btw, some -make docs to contribute too.



Good points! ... what about xxx_WINDOWS_RC_FILES and WINDOWS_RC_FLAGS ? 


not _FLAGS, because rc files aren't flags.


Thanks for your opinion ... what's your preference for the flags variable 
name then ?



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Alex Perez]

Nicola Pero wrote:

So my current inclination (totally open to discussion) is:

xxx_WINDOWS_RC_FILES for the files,
WINDRES_FLAGS for the flags to pass to the 'windres' program

Sounds reasonable ?  Any comments ?


Sounds perfectly reasonable. Perhaps shorten it to _WIN_RC?

The only issue with this solution is that the FLAGS variable is named rather 
differently to the others. As long as the docs are clear I don't see any 
problem. I have, btw, some -make docs to contribute too.



Good points! ... what about xxx_WINDOWS_RC_FILES and WINDOWS_RC_FLAGS ? 


not _FLAGS, because rc files aren't flags.


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Nicola Pero]

> > So my current inclination (totally open to discussion) is:
> > 
> >  xxx_WINDOWS_RC_FILES for the files,
> >  WINDRES_FLAGS for the flags to pass to the 'windres' program
> > 
> > Sounds reasonable ?  Any comments ?
> 
> Sounds perfectly reasonable. Perhaps shorten it to _WIN_RC?
> 
> The only issue with this solution is that the FLAGS variable is named rather 
> differently to the others. As long as the docs are clear I don't see any 
> problem. I have, btw, some -make docs to contribute too.

Good points! ... what about xxx_WINDOWS_RC_FILES and WINDOWS_RC_FLAGS ? 
:-)

(after all, the others too are called OBJCFLAGS and not GCCFLAGS)



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Sheldon Gill]

Nicola Pero wrote:


I did get confused. I changed RC_FILES to WINRES_FILES and RCFLAGS to 
WINRESFLAGS *after* I submitted the patch, not before. (Note, no 'D')


Good point about the 'D'.  The name needs more thinking :-)

Probably you're right and it should be WINRES_FILES rather than 
WINDRES_FILES.


hmmm  I tried to look on the web for how Microsoft calls such a file 
... it looks like it would be called a "resource-definition script (.rc 
file)" 



The compiled resource thing goes back to Windows version 1. They didn't have 
resource forks for FAT16 but wanted it all in a single executable just like 
Word on "that other platform"...


Nonmenclature has varied somewhat, as is typical with MS. They've never been 
very good at tying down technical definitions. Anyway, it was originally a 
"resource script" or "resource script file" which you used to create a 
"compiled resource (file)" which was linked into your executable.
These scripts contained "Menu resource definition scripts" and "Dialog resource 
definition scripts" etc.


Remember also that many a DOS/Win programmer calls them "eksey files" instead 
of programs or applications.


On the Delphi web site they call it "a resource script file", and they 
have the 'Borland Resource Compiler'.  When they get down to real 
business they seem to start referring to it simply as the '.RC file' 
though.


Actually everyone seems to be calling it an '.rc file' after having 
explained what it is.


Pretty much. If you get the properties on such a file you'll find it described 
"Resource script".


So I'm honestly tempted by xxx_WINDOWS_RC_FILES.  It's a bit longer to 
write, but looks like the most expressive / easy to understand, both for 
Windows programmers (who understand it's an .rc file), and for 
non-Windows programmers (who understand it's a Windows-only thing).


We could also go xxx_RESOURCE_SCRIPTS or xxx_RESOURCE_SCRIPT_FILES.


So my current inclination (totally open to discussion) is:

 xxx_WINDOWS_RC_FILES for the files,
 WINDRES_FLAGS for the flags to pass to the 'windres' program

Sounds reasonable ?  Any comments ?


Sounds perfectly reasonable. Perhaps shorten it to _WIN_RC?

The only issue with this solution is that the FLAGS variable is named rather 
differently to the others. As long as the docs are clear I don't see any 
problem. I have, btw, some -make docs to contribute too.



Regards,
Sheldon


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Nicola Pero]

I did get confused. I changed RC_FILES to WINRES_FILES and RCFLAGS to 
WINRESFLAGS *after* I submitted the patch, not before. (Note, no 'D')


Good point about the 'D'.  The name needs more thinking :-)

Probably you're right and it should be WINRES_FILES rather than 
WINDRES_FILES.


hmmm  I tried to look on the web for how Microsoft calls such a file 
... it looks like it would be called a "resource-definition script (.rc 
file)" 
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/tools/about_resource_files.asp).


On the Delphi web site they call it "a resource script file", and they 
have the 'Borland Resource Compiler'.  When they get down to real business 
they seem to start referring to it simply as the '.RC file' though.


Actually everyone seems to be calling it an '.rc file' after having 
explained what it is.


So I'm honestly tempted by xxx_WINDOWS_RC_FILES.  It's a bit longer to 
write, but looks like the most expressive / easy to understand, both for 
Windows programmers (who understand it's an .rc file), and for non-Windows 
programmers (who understand it's a Windows-only thing).


So my current inclination (totally open to discussion) is:

 xxx_WINDOWS_RC_FILES for the files,
 WINDRES_FLAGS for the flags to pass to the 'windres' program

Sounds reasonable ?  Any comments ?

Thanks



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Sheldon Gill]

Nicola Pero wrote:

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

I did get confused. I changed RC_FILES to WINRES_FILES and RCFLAGS to 
WINRESFLAGS *after* I submitted the patch, not before. (Note, no 'D')


It isn't that important, anyway.

Also, on CVS we only add those rules for mingw32.  Maybe we should 
always have


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.


That's the case. Unless you install a mingw32 cross...

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


Yes, windows specific resources for various reasons. I have a suspicion the ELF 
support stems from an idea of Linux native applications which call WINE 
libraries...


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!)


Yes, and I think this is the way to go. It makes it nicely obvious when it 
is/isn't being included and leaves the decisions to the programmer.


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 ?


If you look at it from the "running on Windows" view then Cygwin should have 
it. If you take the "*nix compatibility layer" then it probably shouldn't. As I 
said earlier, I think "leave it to the programmer to decide the right 
conditionals" is the best choice.


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.


For me the motivation to actually get it done was version resources. That way I 
could see it was -base 1.11d build31 and not -base 1.10.3r even though both 
files were called gnustep-base.dll


For very Step applications the main usage would be icons and version info. I 
also use -make for my pure C/C++ stuff thats related. For these projects 
windows resources become more important because they contain images, dialogs, 
strings etc.


Another comment is that in this patch you have $(RCFLAGS) ... maybe 

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


Great.

BTW, there is a secondary reason I wanted windows resources. I have some 
objective-c tools which I'd like to put a GUI face on. An ATL front-end would 
quickly give me a completely native look while the plumbing was objective-c. Or 
I could go silly and write an objc layer on COMCTL32 and friends...



Regards,
Sheldon


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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=Name input file
 -o --output=   Name output file
 -J --input-format=   Specify input format
 -O --output-format=  Specify output format
 -F --target= Specify COFF target
--preprocessor=  Program to use to preprocess rc file
 -I --include-dir=   Include directory when preprocessing rc file
 -D --define [=]Define SYM when preprocessing rc file
 -U --undefine   Undefine SYM when preprocessing rc file
 -v --verbose Verbose - tells you what it's doing
 -l --language=  Set language when reading rc file
--use-temp-file   Use a temporary file instead of popen to read
  the preprocessor output
--no-use-temp-fileUse popen (default)
 -r   Ignored for compatibility with rc
 -h --helpPrint 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 

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

[Sheldon Gill]

Nicola Pero wrote:

Update of patch #3946 (project gnustep):

 Assigned to:None => nico   


___

Follow-up Comment #1:

I was browsing the list of bugs on Savannah when I noticed the list of patches
(I didn't know it was there!), and this patch in particular.

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.



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.



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=Name input file
  -o --output=   Name output file
  -J --input-format=   Specify input format
  -O --output-format=  Specify output format
  -F --target= Specify COFF target
 --preprocessor=  Program to use to preprocess rc file
  -I --include-dir=   Include directory when preprocessing rc file
  -D --define [=]Define SYM when preprocessing rc file
  -U --undefine   Undefine SYM when preprocessing rc file
  -v --verbose Verbose - tells you what it's doing
  -l --language=  Set language when reading rc file
 --use-temp-file   Use a temporary file instead of popen to read
   the preprocessor output
 --no-use-temp-fileUse popen (default)
  -r   Ignored for compatibility with rc
  -h --helpPrint 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...



Regards,
Sheldon


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Nicola Pero]

Update of patch #3946 (project gnustep):

 Assigned to:None => nico   

___

Follow-up Comment #1:

I was browsing the list of bugs on Savannah when I noticed the list of patches
(I didn't know it was there!), and this patch in particular.

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.

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

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 ?

Anyway -- thanks!

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Sheldon Gill]

URL:
  

 Summary: Add make support for windows PE resources
 Project: GNUstep
Submitted by: sheldon
Submitted on: Mon 04/25/2005 at 04:13
Category: Foundation
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open

___

Details:

Add support for compiling windows PE resources into executables & DLLs.

To use this, add appropriate lines to the GNUmakefile in the form of:

project_RC_FILES = project_resource_script.rc





___

Carbon-Copy List:

CC Address  | Comment
+-
nico| This seemed the most reasonable way to
do this.



___

File Attachments:


---
Date: Mon 04/25/2005 at 04:13  Name: make_rc_support.patch  Size: 1.8KB   By:
sheldon
Add support for compiling windows resources into executables/DLLs


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep