I don't think that's a real problem, these files don't change often. It certainly doesn't justify adding a complicated infrastructure to deal with it.
Indeed, I said, and I let it go. But thinking a little more about it, I don't see how you solve the problem with the manual stuff. As I understand it, the problem we need to solve is as follows: -- store rule in Make.rules.in -- handle multiple .rc files per Makefile -- rebuild .res file automatically if .rc or .bmp change
Now, in my proposal we have:
In Make.rules
.rc.extract: bin2res $< && touch $@
%.res: %.rc %.extract $(WRC) -o $@ $<
In make depend:
bitmap1.bmp bitmap2.bmp bitmap3.bmp: rsrc.extract
rsrc.res: bitmap1.bmp bitmap2.bmp bitmap3.bmp
rsrc.extract: rsrc.rc
The only complication here is the .extract file which allows us to split the dependencies from the rules. The complicated stuff are the dependencies, but you need those anyway. A simple marker file is a small price to pay for the convenience... If you think we can keep it simpler, can you please tell me a bit more of what you have in mind? How are we going to use that $(RCBINARIES) if we have more than one .rc file per Makefile?
"Dimitrie O. Paun" dpaun@rogers.com writes:
The only complication here is the .extract file which allows us to split the dependencies from the rules. The complicated stuff are the dependencies, but you need those anyway. A simple marker file is a small price to pay for the convenience... If you think we can keep it simpler, can you please tell me a bit more of what you have in mind? How are we going to use that $(RCBINARIES) if we have more than one .rc file per Makefile?
I don't necessarily think it's simpler, but it's less ugly. We definitely don't want to create dummy intermediate files. But yes in the complex cases we may have to write the rules by hand; I don't think that's a big deal, there aren't that many places that need it anyway. And if it gets really too complex, well then maybe having a #ifdef in the rc file doesn't look so bad...
On Mon, 29 Sep 2003, Alexandre Julliard wrote:
I don't necessarily think it's simpler, but it's less ugly. We definitely don't want to create dummy intermediate files. But yes in the complex cases we may have to write the rules by hand; I don't think that's a big deal, there aren't that many places that need it anyway. And if it gets really too complex, well then maybe having a #ifdef in the rc file doesn't look so bad...
All that to avoid a dummy file?!? But anyway, you did not answer my question :) Can you describe what you have in mind, like giving an example of how you want to handle it, so I can better understand where you're comming from?
"Dimitrie O. Paun" dimi@intelliware.ca writes:
All that to avoid a dummy file?!? But anyway, you did not answer my question :) Can you describe what you have in mind, like giving an example of how you want to handle it, so I can better understand where you're comming from?
To take comctl32 as an example:
# in Makefile
RCBINARIES = idb_std_large.bmp idb_view_small.bmp idb_view_large.bmp RCBINSRC = rsrc.rc
# in Make.rules
$(RCBINARIES): $(RCBINSRC) bin2res -o $@ $(SRCDIR)/$(RCBINSRC)
$(RCBINSRC:.rc=.res): $(RCBINARIES)
We need a way for bin2res to extract a single file for this to work right. And yes, it only works if all the binaries are in a single rc file which happens to be the main rc file, otherwise you need to write multiple rules manually. I don't see how using intermediate files is going to make this any better.
On Mon, 29 Sep 2003, Alexandre Julliard wrote:
We need a way for bin2res to extract a single file for this to work right. And yes, it only works if all the binaries are in a single rc file which happens to be the main rc file, otherwise you need to write multiple rules manually.
Right, this is the point where I didn't see how you can do things manually with the RCBINARIES variable. But if multiple .rc files are not a concern...
I don't see how using intermediate files is going to make this any better.
The one intermediate file is needed for separating the rules in Make.rules and the dependencies in 'make depend'. This also allows it to work with multiple .rc files just fine.
Essentially, if we were to generate the bin2res rule from make depend, we would not need the intermediate file. But if we are to separate the two, we need a way to trigger the bin2res. Thing is that right now bin2res does one pass over the .rc file, and extracts all of .bmp files.
So this .extract (or .binres if you want :)) is a way of saying "OK, we've run bin2res on the .rc file".
I'm not trying to push this too hard, I don't care that much, but since we're discussing it, I'm curious about a few things: -- I don't like that intermediate file that much myself, but why do you think it's such an unthinkable bad idea? We'd add it to .cvsingore, we have plenty of intermediate files... -- Why do you think the proposed scheme would not work?
Oh, and BTW, in this rule:
$(RCBINARIES): $(RCBINSRC) bin2res -o $@ $(SRCDIR)/$(RCBINSRC)
bin2res will update all .bmp files in one go, will make update it's timestamps to avoid running bin2res multiple times?
"Dimitrie O. Paun" dimi@intelliware.ca writes:
The one intermediate file is needed for separating the rules in Make.rules and the dependencies in 'make depend'. This also allows it to work with multiple .rc files just fine.
As long as the .rc file is the one you build the .res from, but that's not always the case, sometimes the .rc is an include (cf. dlls/user).
Oh, and BTW, in this rule:
$(RCBINARIES): $(RCBINSRC) bin2res -o $@ $(SRCDIR)/$(RCBINSRC)
bin2res will update all .bmp files in one go, will make update it's timestamps to avoid running bin2res multiple times?
No it won't, that's why we need to change bin2res to generate only a single file at a time, otherwise it breaks parallel makes. That's also why your intermediate file solution won't work.
I am still lacking the need to have this script. If someone really wants to build parts of WINE on Windows we should really only support MSYS+Mingw or MS_VC. I dont think there are that many people that want to build WINE programs that need extra help. I can try to write better documentation for the MSYS+Mingw build if you want.
Thanks Steven
--- Alexandre Julliard julliard@winehq.org wrote:
No it won't, that's why we need to change bin2res to generate only a single file at a time, otherwise it breaks parallel makes. That's also why your intermediate file solution won't work.
__________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
On September 29, 2003 03:33 pm, Alexandre Julliard wrote:
No it won't, that's why we need to change bin2res to generate only a single file at a time, otherwise it breaks parallel makes.
OK, how about this:
ChangeLog Teach bin2res to deal with one file at a time.
Index: tools/bin2res.c =================================================================== RCS file: /var/cvs/wine/tools/bin2res.c,v retrieving revision 1.16 diff -u -r1.16 bin2res.c --- tools/bin2res.c 18 Sep 2003 20:53:10 -0000 1.16 +++ tools/bin2res.c 30 Sep 2003 18:04:45 -0000 @@ -33,9 +33,11 @@ #endif
static const char* help = - "Usage: bin2res [-x] | [-a] [-f] [-h] <rsrc.rc>\n" + "Usage: bin2res [OPTIONS] <rsrc.rc>\n" " -a archive binaries into the <rsrc.rc> file\n" " -x extract binaries from the <rsrc.rc> file\n" + " -i <filename> archive the named file into the <rsrc.rc> file\n" + " -o <filename> extract the named file from the <rsrc.rc> file\n" " -f force processing of older resources\n" " -h print this help screen and exit\n" "\n" @@ -55,7 +57,8 @@ " bin2res -x myrsrc.rc\n" "Binary files newer than the .rc file are not overwritten.\n" "\n" - "To force processing of all resources, use the -f flag.\n"; + "To force processing of all resources, use the -f flag.\n" + "To process a particular file, use the -i/-o options.\n";
void usage(void) { @@ -118,7 +121,7 @@ return res_file_name; }
-int process_resources(const char* input_file_name, int inserting, int force_processing) +int process_resources(const char* input_file_name, const char* specific_file_name, int inserting, int force_processing) { char buffer[2048], tmp_file_name[PATH_MAX]; const char *res_file_name; @@ -147,7 +150,8 @@ { if (inserting) fprintf(ftmp, "%s", buffer); if (!(res_file_name = parse_marker(buffer, &res_last_update))) continue; - if (!force_processing && ((rc_last_update < res_last_update) == !inserting)) + if ( (specific_file_name && strcmp(specific_file_name, res_file_name)) || + (!force_processing && ((rc_last_update < res_last_update) == !inserting)) ) { printf("skipping '%s'\n", res_file_name); continue; @@ -188,9 +192,10 @@ { int convert_dir = 0, optc; int force_overwrite = 0; - const char* input_file_name; + const char* input_file_name = 0; + const char* specific_file_name = 0;
- while((optc = getopt(argc, argv, "axfh")) != EOF) + while((optc = getopt(argc, argv, "axi:o:fh")) != EOF) { switch(optc) { @@ -199,6 +204,14 @@ if (convert_dir) usage(); convert_dir = optc; break; + case 'i': + case 'o': + if (specific_file_name) usage(); + specific_file_name = optarg; + optc = ((optc == 'i') ? 'a' : 'x'); + if (convert_dir && convert_dir != optc) usage(); + convert_dir = optc; + break; case 'f': force_overwrite = 1; break; @@ -216,7 +229,8 @@
if (!convert_dir) usage();
- if (!process_resources(input_file_name, convert_dir == 'a', force_overwrite)) + if (!process_resources(input_file_name, specific_file_name, + convert_dir == 'a', force_overwrite)) { perror("Processing failed"); exit(1);
-
Alexandre Julliard -
Dimitrie O. Paun -
Dimitrie O. Paun -
Steven Edwards