On Fri, 3 Oct 2003, Pavel Roskin wrote:
I drew an icon more appropriate for the uninstaller. Also, the bin2res tag has been added to make it easier to replace of the icon later.
Please see the latest changes relating to the BINRES tags --> the resources are commented out, and we refer to the filename. See current sources for details.
On Fri, 3 Oct 2003, Dimitrie O. Paun wrote:
On Fri, 3 Oct 2003, Pavel Roskin wrote:
I drew an icon more appropriate for the uninstaller. Also, the bin2res tag has been added to make it easier to replace of the icon later.
Please see the latest changes relating to the BINRES tags --> the resources are commented out, and we refer to the filename. See current sources for details.
That's great news! Hopefully I'll be able to exclude wrc from the script to compile Wine programs on Windows. The new patch goes to wine-patches.
On Fri, 3 Oct 2003, Pavel Roskin wrote:
That's great news! Hopefully I'll be able to exclude wrc from the script to compile Wine programs on Windows. The new patch goes to wine-patches.
You should be able to use windres/rc instead of wrc on Windows now. Please let us know if that is still not the case (or if #ifdefs are still required <shrug/>).
On Fri, 3 Oct 2003, Dimitrie O. Paun wrote:
On Fri, 3 Oct 2003, Pavel Roskin wrote:
That's great news! Hopefully I'll be able to exclude wrc from the script to compile Wine programs on Windows. The new patch goes to wine-patches.
You should be able to use windres/rc instead of wrc on Windows now. Please let us know if that is still not the case (or if #ifdefs are still required <shrug/>).
Everything if fine. I put the latest mkwine here http://www.red-bean.com/~proski/wine/
You can see, it compiles everything except when there the program depends on Wine features. Exceptions: avitools, wineconsole, winedbg, winemenubuilder, winevdm.
There are some minor things windres doesn't like, such as unneeded backslashes. The patch goes to wine-patches.
On October 3, 2003 10:56 pm, Pavel Roskin wrote:
Everything if fine. I put the latest mkwine here http://www.red-bean.com/~proski/wine/
Very nice indeed -- I really hope that we can eventually get our Makefiles in a state where this script is not needed anymore. BTW, since you've studied a bit the problem, what are we missing?
You can see, it compiles everything except when there the program depends on Wine features. Exceptions: avitools, wineconsole, winedbg, winemenubuilder, winevdm.
Yes. Would be intersting to get these to compile on Windows as well, by doing something reasonable where we need Wine stuff. Maybe we at least get them to build, if not run (avitools, winedbg, wineconsole should also be able to run on Windows).
Yes. Would be intersting to get these to compile on Windows as well, by doing something reasonable where we need Wine stuff. Maybe we at least get them to build, if not run (avitools, winedbg, wineconsole should also be able to run on Windows).
as a target: + winedbg should be compilable on windows (except for the ELF support part) => it should work as another debugger + I don't think it's worthwile for wineconsole (it heavily relies on the wine server for getting all it's content, and won't work under windows). So, I'd drop this as a target
A+
On Sat, 4 Oct 2003, Dimitrie O. Paun wrote:
On October 3, 2003 10:56 pm, Pavel Roskin wrote:
Everything if fine. I put the latest mkwine here http://www.red-bean.com/~proski/wine/
Very nice indeed -- I really hope that we can eventually get our Makefiles in a state where this script is not needed anymore. BTW, since you've studied a bit the problem, what are we missing?
I didn't try to use the makefiles, but there are some things that need to be fixed first.
It should be possible to disable WINE_ERR. WINE_TRACE, WINE_WARN and WINE_FIXME can be disabled in include/wine/debug.h, but WINE_ERR cannot. That's illogical because WINE_FIXME is often more serious than WINE_ERR.
Can we have uuid.dll in addition of instead of libwine_uuid.a, compiled from the same sources?
Also one thing unrelated to the make process. Can we make bin2res understand ICON and BITMAP keyword to avoid BINRES? Alternatively, BINRES should go to the same comment as the icon:
IDB_TOOLBAR BITMAP DISCARDABLE toolbar.bmp /* BINRES toolbar.bmp { '42 4D BE ... } */
It would make binres changes less intrusive.
You can see, it compiles everything except when there the program depends on Wine features. Exceptions: avitools, wineconsole, winedbg, winemenubuilder, winevdm.
Yes. Would be intersting to get these to compile on Windows as well, by doing something reasonable where we need Wine stuff. Maybe we at least get them to build, if not run (avitools, winedbg, wineconsole should also be able to run on Windows).
Avitools is trivial, it just doesn't integrate with the script nicely. I'll try to compile winedbg without winedbg.c.
On Sat, 4 Oct 2003, Dimitrie O. Paun wrote:
On October 3, 2003 10:56 pm, Pavel Roskin wrote:
Everything if fine. I put the latest mkwine here http://www.red-bean.com/~proski/wine/
Very nice indeed -- I really hope that we can eventually get our Makefiles in a state where this script is not needed anymore. BTW, since you've studied a bit the problem, what are we missing?
Sorry if it's a duplicate, I'm not sure if my previous e-mail was sent.
We need to be able to disable WINE_ERR like other debug macros.
It would be nice to have uuid.dll instead of libwine_uuid.a. winefile should link against -luuid.
Not related to makefile problems - it would be nice to join the BINRES comment and the resource itself, e.g.
IDB_TOOLBAR BITMAP DISCARDABLE toolbar.bmp /* BINRES toolbar.bmp { '42 4D BE ..
It would make changes to the resource files less intrusive.
-
Dimitrie O. Paun -
Dimitrie O. Paun -
Eric Pouech -
Pavel Roskin