From: Lado B. <lbrisar@MailAndNews.com> - 2000-11-16 19:11:00
|
On 14 Nov 2000, at 19:24, Greg Chicares wrote: > I like this URL > http://www.paulandlesley.org/gmake/autodep.html > where the gnu make maintainer shows how to write your own makefiles > using the autodependency method of automake. Can this method generate dependencies (*.ico, *.bmp, *.cur...) of the resource script (.rc)? I'm using mkdepend.exe for normal #include dependencies. Regards, Lado Brisar. http://lbrisar.htmlplanet.com |
From: Greg C. <chi...@mi...> - 2000-11-17 04:03:05
|
Lado Brisar wrote: > > On 14 Nov 2000, at 19:24, Greg Chicares wrote: > > > I like this URL > > http://www.paulandlesley.org/gmake/autodep.html > > where the gnu make maintainer shows how to write your own makefiles > > using the autodependency method of automake. > > Can this method generate dependencies (*.ico, *.bmp, *.cur...) of the > resource script (.rc)? I'm using mkdepend.exe for normal #include > dependencies. Thanks for raising the question. I overlooked that completely. I've just been using this lame rule: %.res.o : %.rc %.rh The automake technique works for my .rc file: C:\ihs\src>cpp -x c++ -M pmapp.rc -I /owl/include pmapp.rc.o: pmapp.rc pmapp.rh progress.rh \owl\include\owl\inputdia.rc \ \owl\include\owl\inputdia.rh \owl\include\owl\window.rh progress.rc \ version.txt I apply my usual postprocessing, here using the command line (changing '$$' to '$' as make itself would), and the result (reformatting the long lines for posting here) looks OK, but only for dependencies deducible from '#include' statements: C:\ihs\src>cpp -x c++ -M pmapp.rc -I /owl/include > eraseme C:\ihs\src><eraseme sed -e :a -e '/\\$/N; s/\\\n//; ta' -e 's/\.o:/\.obj:/' -e 'h' -e 's/^[^:]*: *//' -e 's/$/ :/' -e 'G' -e 'w eraseme.d' pmapp.rc pmapp.rh progress.rh \owl\include\owl\inputdia.rc \owl\include\owl\inputdia.rh \owl\include\owl\window.rh progress.rc version.txt : pmapp.rc.obj: pmapp.rc pmapp.rh progress.rh \owl\include\owl\inputdia.rc \owl\include\owl\inputdia.rh \owl\include\owl\window.rh progress.rc version.txt Your include path will of course differ. It may seem strange to tell the preprocessor to treat the .rc as a c++ file. The reason I did that is that some included header might conceivably have stuff compiled conditionally on #ifdef __cplusplus But I'm not at all sure about that. It doesn't seem likely that windres would define __cplusplus. I don't even know whether it uses gnu cpp. I'll have to check the source unless someone else already knows. Anyway, lines like this IDI_DOC ICON "mdichild.ico" are ignored, and that's not good. Something like this would work: echo IDI_DOC ICON "mdichild.ico" | sed -e's/^.* ICON /#include /' producing #include "mdichild.ico" and that could be fed into the preprocessor. It's a crude start. We can't just grab strings in double quotes, because of things like POPUP "&File" MENUITEM "&What's This?", CM_WHATSTHIS I think we need to look for ICON CURSOR BITMAP Is that an exhaustive list? Can uppercase be assumed? I think so, because I found windres problems with "Popup". I'll have to check the grammar. I think anything C recognizes as whitespace is OK, including tabs; I know how to handle that. Requiring spaces avoids pathological cases like STRINGTABLE LOADONCALL MOVEABLE DISCARDABLE BEGIN IDS_BAD_ICON, "Icon is invalid" but maybe quotes have to be tested as well: IDS_SILLY, " ICON foo.bar" Then there's this windres icon-on-dialog workaround // email from Lado Brisar Fri, 22 Sep 2000 02:26:28 +0200 myicon1 ICON "appldocv.ico" ICON "myicon1", -1, 2, 2, 21, 20, SS_ICON for which I'm most grateful, yet I'm not clear how to process it so that the nonexistent file 'myicon1' doesn't become a dependency. I searched the web for 'mkdepend' and found many things by that name. Does the one you're using handle dependencies like *.ico ? If no one has a tool like that, I'll try to create one in the form of a makefile that can be incorporated into another makefile with 'include'. I know there are other ways to do it (there are TCL, perl, and C versions of 'mkdepend' out there), but I kind of like make and sed. I do appreciate Paul's comment about the patch manager: > Still, it is recommended to submit things via it. So far we don't > have people who would hunt over mailing to dig out random pearls. And > my IMHO, unlikely will ever have - that's monkey's work. So, if you > think that your contribution is worth of attention - post it there. > Note that they will be carefully scrutinized however ;-) and if I can put together something that seems good enough, I'll place it there. That last line is a little intimidating, like posting to comp.lang.c++.moderated, so I'd like to hear more useful feedback like Lado's first. Personal email is OK if this is off topic on the list. |
From: Paul S. <pa...@is...> - 2000-11-23 03:13:21
|
Hello Greg, Greg Chicares <chi...@mi...> wrote on Friday, November 17, 2000: >> Still, it is recommended to submit things via it. So far we don't >> have people who would hunt over mailing to dig out random pearls. And >> my IMHO, unlikely will ever have - that's monkey's work. So, if you >> think that your contribution is worth of attention - post it there. >> Note that they will be carefully scrutinized however ;-) GC> and if I can put together something that seems good enough, GC> I'll place it there. That last line is a little intimidating, GC> like posting to comp.lang.c++.moderated, so I'd like to hear GC> more useful feedback like Lado's first. Personal email is OK GC> if this is off topic on the list. Please note that there's also a 'Doc Manager' on SourceForge - that may be more suitable for what you plan. With it, you can submit an HTML document, and have ability to edit it afterwards (I hope). When it will be ready for prime time, we will just link it from appropriate www.mingw.org section, but its maintanance will be up (and directly) to you. If you think this is what you want, first try that it is indeed works this way - I never submitted stuff via doc manager, only edited ;-) -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |