Hi,
As there will be a new Gecko release soon, I'd like to give you a good background over what's going on as I feel that there is some misunderstanding on it that I'd like to clarify. I'm sorry for the long mail.
First, let me give you a short history of the Gecko package. As we started using Gecko in our MSHTML implementation, we had to provide our own package and an easy way for its installation. I've prepared a package that actually was a temporary solution. It was a SeaMonkey build that had some files manually removed and modified to reduce its size. It was, of course, hacky and ugly but, as there was no urgent need for changing it, we used it for over a year.
The next version was built by me. The build process was long and ugly - it needed a Windows installation and MSVC6. Except that I had to try many versions before finding one that worked fine for Wine, as it had both to compile with MSVC6 (back then they were switching to a newer compiler that needed actctx) and work with Wine (there were a few APIs that were not implemented in Wine that they started using). Also, there was the XULRunner project that looked promising but proved to not be good enough for us. I ended up with building the SeaMonkey target and, again, modifying and removing some files afterwards.
Now, not only because of CS4 but because we really should follow new Gecko versions as well, the time to release a new package has come. The first decision was to try again by building with MinGW on Windows. I've tried it with limited success and then I found that Mozilla developers have recently worked on building Mozilla with MinGW under Linux (for code analyzers). That was something I hoped to do some day, so I gave it a try and it came out that it works better than compiling on Windows! Also XULRunner project has matured so that we may use it, avoiding other pains from previous packages.
But not all is so good. Some changes introduced in the recent Gecko have prevented Wine from working correctly. It was unnoticed for long time because we were using the 1.8 branch, while the newest is 1.9. Because of it, I had to add serious patches (previous build had only minor changes in code) to fix it. I'm working with Mozilla developers to get these patches to official Gecko. We definitely want to avoid maintaining such differences.
There are other advantages that will come with the new Gecko. I'm going to make a debug build that seems to work really well on Wine. Although it causes an assert in dbghelp that I didn't look at deeper, for one build I was even able to step through Gecko code with winedbg. Hopefully Valgrind will be happy with it.
Also, I'm going to put the code to Git and provide a good building instruction. It's not trivial to build the package, but hopefully with some efforts everyone will be able to succeed with it. In this place I'd like to note: if you're not planning to work on Gecko (I mean not even MSHTML, but Gecko itself), there is no reason to do it. Also I know that some package maintainers would be interested in building it. Please, don't do it! You will realize that it is not possible with a fresh Linux installation without manually setting up environment. Also, due to its complexity, I'm worried about broken builds. I don't really see the reason to do it. If it's a matter of trust policy... well, you've trusted my builds for over three years now, so I'd like to ask you to keep trusting me...
Also, I didn't really have a clear idea about version numbering. The first, temporary, package was numbered 0.0.1. The next one was 0.1.0 with plans to release 0.1.x if we'd release a new package on the same code base (there was 0.1.1 candidate that was never released). My plan was to release a package compiled under Linux as 1.0.0, and until then release next 0.x.y builds. Now that we compile the new package on Linux, I still don't like to call it 1.0.0, because of patches needed in our build. I'd prefer to wait with 1.0.0 hoping to fix the difference for next major release. I don't feel strongly about it so if anyone has any suggestion, I'm happy to change the plan.
I plan to put Wine Gecko code into a public Git so developing it will be easier. Now releasing a new version should be much easier (as long as we won't find a new blocker, but if we'll find it quicker, it will be easier to fix).
I'm happy with releasing the build I've written about a few days ago. I got feedback from Mozilla developer about things we could get to Mozilla tree and I'm going to try to get some patches to Mozilla. That shouldn't delay our release IMO, so I'm going to release tomorrow unless there are any objections. I hope to have another release in a few months that well be closer to main stream Gecko.
Please let me know if you have any suggestion or question.
Thanks, Jacek
-
Jacek Caban