Hi all,
It's time for another Gecko update. I've uploaded to SourceForge [1] new Gecko builds. These are based on Firefox 16 beta. Other than tons of changes inherited from Firefox and usual fixes to keep it working well for us, it brings a few visible fixes:
- Proper <noscript> tag handling - Synchronous ActiveX loading - Possibility to properly call APIs requiring JSContext - Possibility to implement HTMLStyleElement::styleSheet property
As usually, to test it you need the attached patch and Gecko build placed in the right place [2]. Any help with testing is appreciated!
On related note, I seriously consider dropping debug builds and replace them by unstripped release build or even just a separated package containing only debug symbols for the release build. Here are my thoughts about reasoning (in random order):
- People use debug build mostly to retrieve better backtraces. Unstripped builds also give that ability. - If someone really needs debug build, it's easy enough to build it himself (and that's usually a good idea anyway) - Debug builds are seriously different than release build, so it occasionally exposes different set of problems, leading to invalid assumptions. This is really something for developers rather than users. - It costs my time spent builds and tests. And I consider it a serious matter. Amount of work needed to keep Gecko relevant is constantly growing. I try to mitigate it by doing long-term improvements upstream, automating the process and improving my hardware, but that has its limits. And the time spent on Gecko maintenance (as in pure maintenance, not real improvements) costs Wine in terms of improvements I could make in this time.
If someone has a reason to keep debug builds, let me know. Any comments are welcomed.
Thanks, Jacek
[1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.8-beta1/ [2] http://wiki.winehq.org/Gecko
On related note, I seriously consider dropping debug builds and replace them by unstripped release build or even just a separated package containing only debug symbols for the release build.
No one has complained about the debugging symbols in Wine Mono yet. They are included mostly because I don't know how to get rid of them, and it seems silly to put effort into that given the debug symbols have proven useful so far.
On 09/02/12 20:52, Vincent Povirk wrote:
On related note, I seriously consider dropping debug builds and replace them by unstripped release build or even just a separated package containing only debug symbols for the release build.
No one has complained about the debugging symbols in Wine Mono yet. They are included mostly because I don't know how to get rid of them, and it seems silly to put effort into that given the debug symbols have proven useful so far.
Are you suggesting shipping unstripped builds as default package version? That's not an option, xul.dll alone is over 700MB unstripped.
Jacek
Vincent Povirk madewokherd@gmail.com wrote:
On related note, I seriously consider dropping debug builds and replace them by unstripped release build or even just a separated package containing only debug symbols for the release build.
No one has complained about the debugging symbols in Wine Mono yet. They are included mostly because I don't know how to get rid of them, and it seems silly to put effort into that given the debug symbols have proven useful so far.
So, I decided to have a look at ~/.wine/drive_c/windows/mono sizes, and was pretty surprized by the result:
cd ~/.wine/drive_c/windows du -h ./mono 121M ./mono find ./mono -type f -exec strip {} ; du -h ./mono 104M ./mono
So, it's not the debug symbols that creates all that bloat in mono.
-
Dmitry Timoshkov -
Jacek Caban -
Vincent Povirk