All the Perl that's Practical to Extract and Report

wxPerl, wxWebKit, Win32 woes

doubi on 2009-07-01T01:44:44

I can't believe I've spent so long just trying to get wxWebKit working on Windows. The build is finishing at the moment, but some JSCore tests are failing and the example app is being colicky about some dlls and how they're loaded. I'm about ready to shove all this for now and go get working on Linux.

This whole process has been delayed by the fact that there is literally one guy who 'does' wxWebKit. Since the wx port was taken off the Apple buildbot, the folks in #webkit, helpful as they are, don't know anything about it. In #wxwidgets too I'm generally referred to this one fellow who knows the project.

All I feel I've contributed through the project so far is revealing wild inaccuracies in the wxWebKit documentation which held me up for days (the instability of the main WebKit trunk for wx, the existence of the git repo and the inability to compile successfully with MSVC2005), as well as fielding some more basic questions on the wxwebkit-users list and on IRC. As I said in a previous post, being new to so much of this meant not wanting to bug people with my problems before being really sure I wasn't just doing something wrong (especially since there was only one maintainer - didn't like the idea of pissing him off!)

Current status is thus:

  • wxWebKit issues
    It builds, but example app won't run. Author doesn't recognise the symptoms at all:
    • App asks for dlls from a version of MSVC different to the one I compiled it with (msvcp80.dll, msvcr80.dll; I'm using MSVC9/2008) .
    • The dlls should in fact be available as they are in a subfolder of the WINDOWS\WinSxS.
    • Copying them into the app's directory by hand just leads to other errors.
    Pursuing two courses of action:
    1. Use detect.exe to find where the wrong msvc version dependency is coming from.
    2. Try to build on another Windows machine.
    3. Leave Windows for now and get it working on Linux (not a positive course of action, really).
  • wxPerl issues
    • Alien::wxWidgets gives the option to use one's own compiled wxWidgets library, but it requires a gcc build of the wxWidgets library. Ironically, the only way I can currently get wxWidgets to build on my Windows machine is using MSVC 2008's nmake.
    • The reason I wanted to use my own wxWidgets compilation was that wxWebKit requires a wxWidgets build with non-standard settings, specifically wxGraphicsContext. Although the Alien::wxWidgets install script supports the specification of some basic options, the vast majority of WxWidgets options, including wxGC, are unsupported in A::wx's automated build process.
    At first I was just annoyed about this, but the wxWebKit maintainer pointed out that in order to gain any traction, wxWebKit ought to be supported by stock wxPerl installs; Perl devs don't want to muck about building their own support libraries when they're used to CPAN doing it for them. This I suppose points to a new deliverable for my project:
    • Patch Alien::wxWidgets (and possibly Wx itself) to improve flexibility of settings for automatic building of wxWidgets.

The new requirement will in effect have me modifying the existing wx modules on CPAN to enable them to make a wxWidgets build I can use to make wxWebKit... seems a little convoluted, but I guess a simple install method was always going to have to be part of the project. I just imagined having wxWebKit built and working before dealing with those kinds of 'details'.

From here I need to start discussing the feasibility of such a modification on wxperl-users. I've stepped through the code and pretty much get the relevant parts, but there might be wider implications or underlying design decisions I'm unaware of.

In other news, in response to my last post tsee kindly brought this to my attention. Looks to be very helpful :-)

Comments about any topics touched upon in this post and how best to move ahead with the project in general are royally welcomed.

ExtUtils::XSpp

slanning on 2009-07-01T05:38:07

in response to my last post tsee kindly brought [ExtUtils::XSpp] to my attention.

Cool....

About bothering the single maintainer: I can't speak for him of course, but I think for me it's motivating when someone contacts me (though I'm still often too lazy....). They are probably the single maintainer because nobody else "bothers" to help.

Re:ExtUtils::XSpp

doubi on 2009-07-01T15:00:55

Yea I think that is the case. To be fair kollivier has been really approachable and helpful. It's just quite a large build system to get my head around, and he's talking about moving from Bakefile to SCons soon which discourages me from getting into the minutiae of how it works at the moment.

From the perspective of Padre

Alias on 2009-07-01T06:01:50

... we'd move in an instant if we had the option of using WebKit. The default internal shitty browser is horrible.

So there's at least one big user waiting, and we'd be happy to see any changes to Wx core that would allow make it possible.

Re:From the perspective of Padre

doubi on 2009-07-01T15:04:38

szabgab commented on my original proposal to that effect. It's pretty motivating to know there's a waiting consumer for the work I'm doing :)

Apparently the changes mightn't be as far-reaching as I'd thought (see mattia's comment). My apologies to the wxPerl team!

Alien::wxWidgets

DiamondInTheRough on 2009-07-01T06:05:43

Ironically, the only way I can currently get wxWidgets to build on my Windows machine is using MSVC 2008's nmake

I'm surprised. It builds quite well for me!

Re:Alien::wxWidgets

doubi on 2009-07-01T14:57:15

The frustrating thing is that it does build fine for me with nmake, but using the configure script then make'ing in cygwin throws up all kinds of errors.

Can I ask what kind of environment / configuration you're building with?

Re:Alien::wxWidgets

DiamondInTheRough on 2009-07-01T15:44:57

OOPS. Thought you meant Alien::wxWidgets, not wxWidgets by itself, without the Perl build script.

I'm the one working on the Strawberry Perl betas for this months release - so I just use the installation of GCC that comes with Strawberry Perl and Alien::wxWidgets builds just fine. No cygwin required.

[I think Alien::wxWidgets is preconfigured for Win32/Strawberry Perl, so you may have to manually edit the configuration headers in order to change things. I'd have to look at it for specifics, and I had 4 hours of sleep last night. And I hope that wxWebKit will build in a Strawberry environment when all is said and done, btw...]

Re:Alien::wxWidgets

doubi on 2009-07-01T16:22:10

Ahh, I see. Yes, Alien::wxWidgets install and builds the source painlessly for me too. And I definitely intend that it will work with Strawberry; I think that's a necessity :-)

Alien::wxWidgets & MSVC

mattia on 2009-07-01T10:37:45

FYI, Alien::wxWidgets does not require GCC neither when using a pre-built wxWidgets nor when it builds wxWidgets itself (bugs happen, but that is a different story).

Re:Alien::wxWidgets & MSVC

doubi on 2009-07-01T14:54:14

I clearly need to examine the code in more detail. I just jumped to where I thought the problem was, I didn't notice there's a whole set of other modules for msvc. Thanks for pointing that out, & sorry I didn't give your system enough credit!

I'll be in touch to ask about the build flags. IRC always seems pretty quiet when I've popped in with questions, I must be in an inconvenient timezone (or asking silly questions ^^; )