Jacek Caban wrote:
Sent: Nov 17, 2009 7:40 AM To: Tom Wickline twickline@gmail.com Cc: James Mckenzie jjmckenzie51@earthlink.net, Vincent Povirk madewokherd+8cd9@gmail.com, wine-devel@winehq.org Subject: Re: today's git broke winetricks gecko :-(
Tom Wickline wrote:
On Tue, Nov 17, 2009 at 10:27 PM, James Mckenzie <jjmckenzie51@earthlink.net mailto:jjmckenzie51@earthlink.net> wrote:
> +1 as well. Not all UNIXes have Gecko support packages built for them+1 as well, I haven't tested the changes on OpenSolaris yet, but I plan to. :)
Which makes -0 from both of you as you clearly don't understand the way Gecko package works. These are .dll files so they are only arch dependent from Wine point of view.
Are there not installer packages for the different UNIXes for Gecko? If there are not, then the package should install everywhere, including MacOSX and OpenSolaris. If they are system/OS dependent, then my comment stands.
James McKenzie
On Tue, Nov 17, 2009 at 8:52 AM, James Mckenzie jjmckenzie51@earthlink.net wrote:
Are there not installer packages for the different UNIXes for Gecko? If there are not, then the package should install everywhere, including MacOSX and OpenSolaris. If they are system/OS dependent, then my comment stands.
Nope, there's just wine_gecko-1.0.0-x86.cab and wine_gecko-1.0.0-x86-dbg.cab. 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.
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.
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?
Cheers,
Peter Urbanec
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
On Tue, Nov 17, 2009 at 9:54 AM, Peter Urbanec winehq.org@urbanec.net wrote:
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.
While I am much less annoyed now that things are working, I'd still like to see an option for specifying the .cab file path at run time, and for disabling the dialog completely. Maybe I'll write some patches.
And apparently the difficult build process is being worked on but is a hard problem to solve, so I'm satisfied with that. It's good to know there aren't any real closed-source components needed to build, just unusual versions / changes to open-source components.
It sounds like the the unusual version requirements and hacks are mostly the result of bugs in other projects that are tracked in their bug trackers, and of the need to build a PE gecko on Linux rather than a winelib gecko (which is itself needed because of the difficult build process, which is because of bugs in other projects). Is this accurate?
Vincent Povirk wrote:
On Tue, Nov 17, 2009 at 9:54 AM, Peter Urbanec winehq.org@urbanec.net wrote:
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.
While I am much less annoyed now that things are working, I'd still like to see an option for specifying the .cab file path at run time, and for disabling the dialog completely. Maybe I'll write some patches.
I'm not fan of this idea, but we may talk about patches once they will exist. For your (unusual IMO) case of multiple installations it might be worth to consider a special target for 'make install' that would check if gecko is available in $build_dir/../gecko and copy it if it does.
And apparently the difficult build process is being worked on but is a hard problem to solve, so I'm satisfied with that. It's good to know there aren't any real closed-source components needed to build, just unusual versions / changes to open-source components.
It sounds like the the unusual version requirements and hacks are mostly the result of bugs in other projects that are tracked in their bug trackers, and of the need to build a PE gecko on Linux rather than a winelib gecko (which is itself needed because of the difficult build process, which is because of bugs in other projects). Is this accurate?
Yes, it's true except for mingw. I've filled one bug for them and there was no interest. I also can't send them patches because they don't agree with the way Wine includes are created. I've chosen to provide our own includes for these problems that are fixed mingw headers or just Wine replacements.
I also don't see much point in winelib builds so I don't plan to work on it myself. It will make things harder to support. The only real point I can see is if we wanted to provide a package for architectures are not supported by PE. Anyway, once mingw builds will work good, it should be much easier to change.
Jacek
On Tue, Nov 17, 2009 at 11:08 AM, Jacek Caban jacek@codeweavers.com wrote:
I also don't see much point in winelib builds so I don't plan to work on it myself. It will make things harder to support. The only real point I can see is if we wanted to provide a package for architectures are not supported by PE. Anyway, once mingw builds will work good, it should be much easier to change.
For me, the point would be that a lot of build dependencies could be eliminated, once the other tools have generally-available fixes, and then maybe more people could build gecko as part of the normal process.
Or is this not true?
Vincent Povirk wrote:
On Tue, Nov 17, 2009 at 11:08 AM, Jacek Caban jacek@codeweavers.com wrote:
I also don't see much point in winelib builds so I don't plan to work on it myself. It will make things harder to support. The only real point I can see is if we wanted to provide a package for architectures are not supported by PE. Anyway, once mingw builds will work good, it should be much easier to change.
For me, the point would be that a lot of build dependencies could be eliminated, once the other tools have generally-available fixes, and then maybe more people could build gecko as part of the normal process.
Or is this not true?
It is true, but it will lead to a lot of different problems. We may rethink it when we'll get at least near to the point where it won't be a theoretical discussion.
Jacek
On Tue, Nov 17, 2009 at 10:52 AM, James Mckenzie jjmckenzie51@earthlink.net wrote:
Are there not installer packages for the different UNIXes for Gecko? If there are not, then the package should install everywhere, including MacOSX and OpenSolaris. If they are system/OS dependent, then my comment stands.
As Jacek pointed out, there are not any different installers for each Unix...there is no installer, just a cab file put in the right place (or downloaded on wineprefix creation). Please investigate such obvious issues before complaining about them (especially a second time after it was already explained).
-
Austin English -
Jacek Caban -
James Mckenzie -
Peter Urbanec -
Vincent Povirk