Peter Urbanec wrote:
Vincent Povirk wrote:
Distro-specific packages just put the
.cab file in the right place. Gecko binaries target windows, not unix
(hence the need for mingw) so they really just depend on a functional
x86 Wine.
There's a lot of talk about the new Gecko requirement. At the end of
the day, adding the .cab file to a binary distribution was a trivial
10 minute exercise. It took another 20 minutes to test everything and
figure out that the wiki page was wrong and the .cab file needs to go
in $PREFIX/share/wine/gecko NOT in $PREFIX/share/gecko. The wiki page
is now fixed, so it really should be trivial to add the gecko runtime
to most binary distributions.
Sorry about that. I've noticed it trying to help Vincent to install Gecko.
Yes, my new wine binary package has doubled in size due to a HTML
component that is actually never used directly by the target
application. A bit of a bother, but if the inclusion of the gecko
binary blob as a .cab file means more reliable wine runtime, it's a
small price to pay.
At the end of the day, the only objection I have is the fact that
building the binary release of the .cab file from source is such an
ordeal. It would be nice if the requirement for gecko could be
satisfied as part of the normal wine build process.
Jacek, any ideas on what could/should be done to align the Gecko build
process with the wine build process? Is it possible to have minimal
Win32 stubs and keep most of the Gecko engine native?
Unfortunately it's not so easy. We would have to compile Gecko with
winelib target. We already have a lots of problems with Mozilla build
system to cross compile it and I'm expecting much more problems if we
tried to use winelib. Perhaps someday it will be possible, but wouldn't
expect it in the near future. Also it would mean that the build wouldn't
be portable across distros, but it's not an issue for distro packages.
Jacek
