Support compilation on Linux for version 2.0

[jleveque]

• Tweaked my previous CMakeLists.txt file to work with theoraplayer v2.0
• Fixed a few Linux compilation errors
• Currently building ogg, vorbis, theora and theoraplayer libraries as well as glut_player demo

[kspes]

@borisblizzard forgot about this pull request, what do you think? Check the diff, should we include this in the master branch?

[borisblizzard]

Seems more or less ok. I suggest that -D_UNIX is added and maybe we can remove the enc* files from complication since they aren't actually used. We only compile encoder_disabled.c and enquant.c as far as I can see in our VS setup.

[kspes]

agree. did you check the source changes too? not just the cmake file. maybe we should put the cmake file in a separate folder like we do with xcode and msvc?

[borisblizzard]

I agree with moving cmake into its own directory. This might make it easier to switch things around in the future. Source files seem ok, just a few additional header includes and a convention fix.

[kspes]

merged and verified, all seems to be ok. cmakeLists is in root actually which is ok, forgot we only checkout the theroaplayer folder as externals.

[jleveque]

Thanks for merging this, It's good to have Linux support.

@borisblizzard: I'm just curious as to why you disable encoding in your build of the theora library. Is it simply to keep the size down? I find it helpful to have a theora lib that I can both decode with (using libtheoraplayer) and also encode with, so I always have to manually add the encoding support back in libtheora when I build libtheoraplayer for both Windows and Linux (which is my the enc* files are included in the CMakeLists.txt I submitted). Would you consider adding the encoding support when building libtheora by default in this project, or is there some other reason you are opposed to it?

[borisblizzard]

I think we mostly removed it due to size and the fact that we have only ASM optimizations for decoding. I guess we could add it. Kreso, what do you think? I see no reason not to (unless we're getting compiler errors).

[kspes]

yes, we removed it to reduce size. and theoraplayer isn't designed for encoding purposes. if you need to use encoding and specifically theora, it's best if you use your own compilation environment. We have webM and we support apple's AVFoundation backend, and each of them has encoding done differently. it would not be systematic to include encoding in our theora library I think if it's not designed to be used in theoraplayer. The lib doesn't include sources of theora on purpose, you can always supply your own theora distribution if you need special functionality.

[jleveque]

@kspes: I understand where you're coming from. However, I like to use the same version of the library for both encoding and decoding to ensure what is encoded will be decoded properly (not to mention it is quite inconvenient to manage two versions of the lib). Since I use theoraplayer for decoding and it has the ASM optimizations, I always need to reconfigure the projects to add encoding support to libtheora whenever I rebuild libtheoraplayer so that I can use the same lib for encoding.

I'd like to ask you to reconsider this decision. As a suggestion, for the Windows solution, you could simply add a few more build targets that one could optionally choose if they would like to enable encoding support in theora. Does that sound reasonable?

[kspes]

@borisblizzard I suppose it couldn't hurt to add a new target to libtheora bundled with the project?

[borisblizzard]

Yeah, sure. I'll take care of it on Monday.

[borisblizzard]

Added. Compilation, linkage and running seemed fine, haven't tested if the encoder works, though.