N/A
I don’t have Fedora myself, so I have no way to try it. We’ll be happy to help you get it building if you want our help, but you provide no information, so we can’t help you yet.
I don’t know what posts you’re referring to about blaming gcc. Certainly each different version of gcc has its own set of quirks and bugs; and some of these have been known to cause problems to Panda and other big systems over the years. But we don’t use any fancy bleeding-edge syntax.
If you’re an experienced programmer with a basic understanding of Python code, you can understand makepanda with very little difficulty, and it’s not clear that a more standard build system would be any easier to understand. We have discussed migrating to other build systems, but Panda is a big system and this would be a lot of work; and in any case, autotools would be a poor choice, as it’s really only suitable for Unix-based systems.
David
We’ve historically always supported Fedora, but at one point I had to pull the Fedora builds for the last release because of a bug in the build system that generated bogus RPMs. I think there are daily builds for Fedora, but that’s Fedora 14.
Anyway, it should be possible to build on Fedora. You should let us know when you run into any specific issues. The main thing is installing all of the thirdparty packages. You’ll probably need to add RPMFusion to your repositories to get packages such as ffmpeg. For the record, here’s a list of packages I installed back when I compiled Panda3D for Fedora 14:
redhat-lsb python-devel bison flex libtiff-devel libpng-devel gtk2-devel openssl-devel gcc-c++ libstdc+±devel freetype-devel libjpeg-devel mesa-libOSMesa-devel libXft-devel mesa-libGL-devel mesa-libGLU-devel opencv-devel ffmpeg-devel nspr-devel xulrunner-devel ode-devel Cg openal-soft-devel gtk2-devel zlib-devel libX11-devel libXxf86dga-devel libXrandr-devel
You may not need all of these packages. For instance, nspr-devel and xulrunner-devel only apply to the runtime build, not to the SDK build. libOSMesa is only necessary if you want to use the outdated, deprecated mesa renderer. The list is also missing libraries such as libBullet and libRocket and libXcursor, support for which has been added since I made that list.
As for the build system; I agree that we need to switch to a more standard build system, these plans have already been there for months. However, I think autotools would be a bad choice (for many reasons), as popular is it may be; we were planning to migrate to CMake, which suits our needs and enjoys a steadily increasing amount of support. Many popular open-source projects now provide CMake files alongside their old autotools files.
Migrating a big project like Panda3D to a new build system isn’t straightforward, but I do put a big priority on this todo item.
There hasn’t been all that much interest in Fedora, and the Fedora releases come out so rapidly that it’s difficult for me to keep up - every time a new Fedora release comes along, I have to set it up a new build system. However, recently I’ve been hearing more and more clamour for it, so I’ll try and get the latest Fedora release supported in 1.8.1.
N/A
Could you give us the log files from your Panda3D log directory in application data?
There are many reasons for us to choose CMake over autotools, including autotools’ lack of proper support for the MSVC compiler, the Windows environment in general, the complexity of its configuration, etc. CMake does all the things our current build system does and more, including testing and packaging. Many open-source projects seem to be switching from autotools to CMake for these and other reasons, and my early tests have shown that migrating to CMake is a lot less painful than migrating to autotools. Is there any reason why CMake would be unsuited?
Cross-compilation for Windows is simply out of the question for a project of Panda’s complexity, especially when we try to compile against proprietary MSVC-only libraries such as the DirectX SDK and the Max/Maya SDKs.