I’m continuing the work to make xine build (and hopefully work) on OS X, that I already started talking about a few days ago.
Again, the main problem of getting xine to build on OS X is to make the build system aware of it; I started the work on this some time ago by letting the configure understand the difference between PowerPC and Darwin, but that was just the first step of a long journey.
After the other night, though, there has been a bit of a stall, as the fixes I committed, cleaning up the configure.ac, ended up using some features coming from autoconf 2.60, so Bastien Nocera (Totem’s author) reported some problems when building with 2.59. As nobody but him seems to have noticed a difference, and as autoconf is just a tool for developers rather than for the users, I’ve updated the pre-requisite declaration on configure.ac and I’m waiting to hear from the “council” of the xine developers to see what they think about it. I suppose that 2.60 macros will be welcome to be used on the long run anyway.
Now, I have to say that the autoconf and automake code I found when I first started fixing xine, before being a developer and just helping out with Gentoo, was really messy, and it still is for the most part, at least for the code that hasn’t been updated yet.
Today I even found an install and uninstall rule for the default headers, that were being rewritten just to change the destination directory (while it would have been enough to just change the name of the headers’ group, and then replaced its foodir variable).
So from this side, overhauling the configure code is a good idea; with the changes I’ve been doing, the time requested to run the configure should be way shortened; unfortunately there are other problems like pkg-config checks that currently miss the AC_MSG_RESULT and a few tests that should be cached.
Adding a test for a GNU assembler wasn’t easy either, as I had to copy for a GNU ld from libtool, and adapt it.. but then Apple’s assembler reports itself as GNU as (1.38), which doesn’t support the syntax I needed, so I had to adapt the macro to consider Apple’s assembler a non-GNU one. Now I could make the Win32 codecs disabled by default when building on OS X with non-GNU assembler (if you were to use GNU binutils and thus GNU assembler, it would build it, probably, not sure if it works though).
This solved the problem I left the other day, but of course there were more to come, or Murphy wouldn’t be so famous. So there I was again to hack on the configure, as the planar post plugin required a byte-alignment instruction (.balign) not available on the Apple as; I then worked differently the code for the ASMALIGN macro from FFmpeg to have it available on the entire source, allowing me to use it where needed, so that the planar plugin built (thanks exg for the help here).
And was this the end? No of course, now there is the greedy deinterlacer, requiring more registers than needed, that intends not to compile on OS X, not even with -fomit-frame-pointer… the code probably has to be rewritten, maybe the big asm chunk split in simpler parts, but I’m not a big ASM expert, so I’m not sure how I’ll do that.
Anyway, I haven’t given up yet, although the road is still long… just never ask me to do this for Windows !
The problem instead is that tonight, talking with eean and leinir on #amarok, I understood there are a lot of pitfalls in the current xine code, that will be evident as soon as Phono is going to be used for system sounds in KDE: the plugin cache does not work, other then being a human readable text file (which makes parsing slow, compared to a binary cache), and crashing on some invalid data (there’s a bug open for that), the fact that configuration entries are never cached makes it pointless for those plugins having a preload flag enabled. Also, the memory waste I talked about makes even more sense now, especially because by using multiple instances, using mmap to read the files improves the situation a lot, as they can share the same memory area for the same system sounds, even between users, and if I can make the mmap being the only source of data for the library, rather than having to copy it around over and over, it will not add extra memory footprint on them.
I think I’ll have really to study more about memory management, if anybody has a suggestion, it’s very welcome.
And seeing the amount of work that I’ll probably have to pour into xine in the next months thanks to KDE 4, donations are even more welcome, especially when they come with a sample of a file not playing correctly to be fixed… better now than when people cries because they can’t use their sounds for the events. (I don’t like saying it this way, but I admit I was a bit upset when an user seemed to demand that xine resumed playing very old Ogg files, saying that the fact the format is crappy does not make the problem any less real… sure it’s a real problem, but I’m already doing quite bit for xine, and I’m almost alone.. and I know I’ll burn out when people will start demanding improvement in xine just because it’s being used by KDE 4!)
[Would it be worth asking again on xine-devel to give me a better SCM to work with? CVS is really giving me creeps, and making it almost impossible to start working on a 1.2 series… or even a separate branch for a new feature, like the memory thing]