[RFC] Winelib enhancements
Dimitrie O. Paun
dpaun at rogers.com
Thu Nov 28 00:35:42 CST 2002
Folks,
You are probably familiar with the Winelib page:
http://www.dssd.ca/wine/Winelib-Apps.html
where I describe what one needs to do to compile
a Win32 application under Winelib.
My original motivation for doing the work was to better
understand what inconveniences one has to go through
to do the port, and what we can do to eliminate them.
Here are my thoughts on the subject, in the build order:
Compilation
This step require the addition of some flags, and the
potential removal of others. Simple to do, and if there
is a configure script, quite doable.
However, these tweaks are really annoying in the initial
stages of the port, and would be so nice if we had a nice
compiler wrapper (call it wcc) that would do that behind
the scenes, so that the only modification to the makefile
would be:
-CC=gcc
+CC=wcc
Q: Alexandre, would you accept such a utility in the tree?
Resources
These ones are nasty. Programs typically use the windres
compiler that compiles a .rc file into a .o file directly,
which is later simply linked into the application.
We go a different route, by sticking the resources in the
.spec.c files, and this entails non-trivial modifications
to the makefiles. The ideal option would be to provide a
windres compatible command line mode for wrc, so that we
can do:
-RC=windres
+RC=wrc
This would mean moving the resources out of the .spec.c
file, and exporting the resources variable so we can link
it into the .spec.c file.
Q: Alexandre, is this acceptable? Does it warrant discussion?
Linking
Another tricky step, with multiple problems
1. We are missing import libraries. As a result, we can not
link with -lwinspool, we need to link with -lwinspool.drv
Small change, but it can present nasty problems if you want
to submit the patch upstream, to the application maintainers.
I understand this one is already on Alexandre's TODO, so
we should have a solution to it not before too long.
2. Our linking process is quite different from the "standard"
one which uses gcc/ld to do the linking. We generate
intermediate files (.spec.c files), and use different flags.
Again, the solution for this (to at least help initial
porting efforts) would be a wrapper script that does this,
that can be used instead of ld. And so the question comes
back again, to haunt us: is this needed/wanted/acceptable?
Running
This is a new step in the process that we introduce. Currently
we produce a shared library that requires a wrapper script to
start it up. Many considers this (and I might say rightfully so)
ugly/bloat/etc. The ideal situation would be to generate regular
executables, like all well behaved libraries.
Here are a few solutions:
1. An interim step is to improve the wineapploader script so that
it can be used by all apps. This is a simple thing to do at the
moment, but does not solve the root cause, it just ease the pain
a bit. This way you don't need to fight the application
maintainers to get such script included in their tree, and having
to answer the eternal questions: "WTF is this? I thought that
compiling under Winelib would yield an executable that did not
need wine. What's the difference as compared to running the Win32
binary directly?"
2. Fix the build process so that we can actually generate regular
executables. Thing is, I don't know what's involved in doing so,
and I'm afraid only Alexandre knows the answer (hint, hint :)).
So a discussion on this topic is needed, just to figure where
we want to go from here.
Now, this message is meant to elicit discussion on these topics, so
that at the end of the day I can gather the conclusions, and track
them on TODO page. So do not hesitate to send in your comments. :)))
Thanks for your attention, and sorry for the long message.
--
Dimi.
More information about the wine-devel
mailing list