2007-07-24, 02:59
Hullo peeps. 
I was shown XBMC earlier today, told about the Linux port, and decided it looked like it might be something I'm interested in contributing to. I've checked out the source, and having taken a very brief look over it and attempted (so far without luck) to build it, I have a few questions that might help me decide whether or not this project is really for me.
First of all: I noticed from the forums that it's a "known issue" that it won't compile on AMD64 hardware, which I am using. This is the prominent reason why I haven't got it to compile yet.
I saw that a few people were interested, but assume things aren't very far along yet. A lot of the problems seem to be due to casting things from pointers to very specific types: what are some of the reasons for this, and would a preferred solution be casting to different types, or cleaning up code that pretends pointers are integers (obviously a larger task, but I'm fairly certain I've already found one place where the conversion to integer types is largely unnecessary with a little rethinking)? I've been cleaning up casts as they crop up, but suspect that this would take a long time for the whole code base, and have no idea whether the resulting binary would actually run! 
Secondly, checked-in pre-built DLLs and SOs. I read that the source for most/all of these was also checked in - fair enough, so they can be rebuilt. What about DLLs? Are these used at all in the Linux version, and if so will there ever be 64-bit replacements? (I have to admit it's not something I've studied, but based on what I do know, the standard response to anyone trying to load a 32-bit DLL from a 64-bit program is "good luck."
)
Thirdly, the build system. I see some attempt has been made to move to an autotools-esque system, but this has not been fully realised. For example, despite the configure script detecting "gcc" and "g++" as CC and CXX respectively, some other hard-coded part of the system forced them to "gcc-4.1" and "g++-4.1", which doesn't work on my distro (I hacked around it temporarily, just to get a build started). Are there plans to increase the use of autotools, and/or would patches aimed at this be welcomed? It would be nice if, in future, one could simply configure & build everything in the tree, including the parts currently supplied pre-built (assuming source is available).
On a more general note, since I haven't had a thorough look at the code yet (and at this point wouldn't know here to start), I'd like to ask how much of the back-end code - filesystem support, codecs, etc. - has been hand-rolled, and how much is taken from external libraries, since other than the obvious (SDL, OpenGL), the Linux port seems a bit thin on the ground in terms of external dependencies. Which may be a good thing, depending on the reasoning behind it.
I don't actually have an xbox at the moment; my main interest in the project comes from experience with MythTV, which - at least in GUI terms - looks like something written in a weekend when compared to XBMC.
I was shown XBMC earlier today, told about the Linux port, and decided it looked like it might be something I'm interested in contributing to. I've checked out the source, and having taken a very brief look over it and attempted (so far without luck) to build it, I have a few questions that might help me decide whether or not this project is really for me.
First of all: I noticed from the forums that it's a "known issue" that it won't compile on AMD64 hardware, which I am using. This is the prominent reason why I haven't got it to compile yet.
I saw that a few people were interested, but assume things aren't very far along yet. A lot of the problems seem to be due to casting things from pointers to very specific types: what are some of the reasons for this, and would a preferred solution be casting to different types, or cleaning up code that pretends pointers are integers (obviously a larger task, but I'm fairly certain I've already found one place where the conversion to integer types is largely unnecessary with a little rethinking)? I've been cleaning up casts as they crop up, but suspect that this would take a long time for the whole code base, and have no idea whether the resulting binary would actually run! Secondly, checked-in pre-built DLLs and SOs. I read that the source for most/all of these was also checked in - fair enough, so they can be rebuilt. What about DLLs? Are these used at all in the Linux version, and if so will there ever be 64-bit replacements? (I have to admit it's not something I've studied, but based on what I do know, the standard response to anyone trying to load a 32-bit DLL from a 64-bit program is "good luck."
)Thirdly, the build system. I see some attempt has been made to move to an autotools-esque system, but this has not been fully realised. For example, despite the configure script detecting "gcc" and "g++" as CC and CXX respectively, some other hard-coded part of the system forced them to "gcc-4.1" and "g++-4.1", which doesn't work on my distro (I hacked around it temporarily, just to get a build started). Are there plans to increase the use of autotools, and/or would patches aimed at this be welcomed? It would be nice if, in future, one could simply configure & build everything in the tree, including the parts currently supplied pre-built (assuming source is available).
On a more general note, since I haven't had a thorough look at the code yet (and at this point wouldn't know here to start), I'd like to ask how much of the back-end code - filesystem support, codecs, etc. - has been hand-rolled, and how much is taken from external libraries, since other than the obvious (SDL, OpenGL), the Linux port seems a bit thin on the ground in terms of external dependencies. Which may be a good thing, depending on the reasoning behind it.
I don't actually have an xbox at the moment; my main interest in the project comes from experience with MythTV, which - at least in GUI terms - looks like something written in a weekend when compared to XBMC.
