Linux support

[LiamDawe]

So what is needed for it?

[Stelminator]

Ok, so, I worked on Linux/Mac support as recently as September 2010. Don't let that date scare you, it's quite recent enough, the trouble starts with binary dependencies and features that never got ported to Mac or Linux. We haven't really messed around with the binary stuff much since some time before that date, so that means most things I got working then, should still work.

It's mostly a matter of dependencies. If all of those work, the rest becomes possible; there are some things that will need to be ported, but getting to a point where we can actually work on that must come first. Careful with the dependency wx, for Digsby, this refers to wxpy that, in turn, will need wxWidgets and webkit. etc.

Thankfully, a lot of the work that went into the open source initiative resulted in isolating many dependencies. I'd start by trying to make a virtualenv with all the dependencies, and porting the buildout.cfg to do the right thing on linux for just the pure Python dependencies. Then, move on to the python libraries with binary extensions. There are a lot of binary libraries required to build other extensions, I'm not sure the right way to go about getting those on Linux. If you get to the "build_all.py" step in the readme for digsby, it's almost there, and that'll be the difference in build scripts since the last time anyone tried to build Mac or Linux.

The more fun version is try to run "python Digsby.py" and tackle things in the order that they break. A successful port will employ this method at some point, anyway.

Ok, I think that's enough of a braindump. Next (probably more specific) question, please. :-)

[Psykar]

I'm working through all the dependencies slowly - luckily most of them can be installed via 'pip' rather easily.

The crappiest one I've come across so far is 'peak'
Download the tarball from here:
http://svn.eby-sarna.com/Plugins/

And python ./setup.py install it.
Seems as though the pip package for it is invalid :(

Thanks for the info, that wxpy dependency is a little bit of a gotcha.
My current stickler is installing the wx branch, which is trying to run 'nmake' which is a windows only tool.
Also a couple of issues with trying to build xmlextra - although I'm not convinced this is required just yet.

[Stelminator]

xmlextra is from pyxmpp, right? I think you can skip it for now, iirc, there's a pure python fallback, though I prefer the binary extension work.

I would stay away from the official versions of PEAK right now, we have major differences, mostly to support python 2.5+ correctly, and until that's properly dealt with, I suggest you stick Mike's fork, as listed in buildout.cfg. Additionally, keep in mind that PEAK has many different packages, Mike's "fork" has several rolled into one.

Regarding wx, this sounds familiar, unfortunately. I don't think I ever unified the wx branch. This will be a point to work on. However, that doesn't completely stop you from making progress. Take a look at digsby/build/build-deps.py. I think if you run that as "python build-deps.py --wx --webkit", you might get a little farther, but certainly more broken. If you run into anything that says "mini", you're going to have to turn it off/work around it, as that was our internal source server, and that machine isn't even turned on anymore. Additionally, you might be able to jump-start wx on linux by grabbing an official package, but I make no guarantees about version compatibility or library paths, etc.

[mikedougherty]

For ease of setup I agree with Chris - try to grab the variants listed in buildout.cfg -- but if someone were to make an attempt to get 'stock' packages working, I wholeheartedly support that effort.

(also fyi Chris - I'm 99% sure we got all the 'mini's out of there)

[Stelminator]

@mikedougherty nope, I checked. still a couple in digsby/build/constants.py, where "MINI_LOCAL = True". That gets used by digsby/build/build-deps.py, which was the way to get things going on Mac/Linux.

[mikedougherty]

ah, you're right. my mistake. of course I was only thinking of the windows code path 🙊

[Psykar]

Luckily it looks as though the only MINI reference is
boost = tardep('http://mini/mirror/', 'boost_1_42_0', '.tar.gz', 40932853, dirname = buildDirs.boostDir)
which it appears we can get from build_cgui.py:
boost = tardep('http://iweb.dl.sourceforge.net/project/boost/boost/1.42.0/', 'boost_1_42_0', '.tar.gz', 40932853)

I was hoping to be able to use stock wxpython, but it appears you've got a custom module 'wxpybuild' in the wxpy branch, so seems that has to come first, given you need it to compile boost :(
I believe boost is only needed for it's 'cgui' module, I did find a cgui module in xbmc's source (of all places!), but I doubt that's the same thing.

Is wxpybuild and cgui derived from elsewhere? Or are they written entirely by @tagged ?

Appreciate the assistance!

[Stelminator]

https://github.com/tagged/digsby/tree/master/digsby/ext/src
cgui is a binary extension, as part of digsby, as is blist; any name collision with other projects is coincidental. Only needing boost for cgui sounds right. wxpybuild looks Kevin's work (so, mostly original code). I see path.py in there, which is it's own project, and I think there's at least one modified version in the digsby source somewhere.

sip is probably going to be necessary. It's a pre-req for wxpy and cgui; I don't remember if it's needed for blist. You've reached the limit of my working memory/knowledge on this specific topic (wxpy). Perhaps @kevinw could jump in and give us some wisdom. Otherwise, yeah, you'll probably have to dig through and untangle it.

[LiamDawe]

It may be better to put up a couple TODO issues for Linux support to be easier to track for users and developers interested rather than having to read through this whole issue with everything crammed in?

[kevinw]

Because of our particular constraints, we forked SIP, and rewrote wxPython, and used basically a frozen fork of wxWidgets 2.8, with miscellaneous fixes specific to Windows.

But I think moving forward, it might be best to concentrate on using stock versions of all of these libraries. I'll see about adding a detailed "dependencies TODO."