Latest CVS is still broken (seems like a whole bunch of files are missing), but I managed to fix the audio issues by copying what I deduced where your latest code drops over to the previous build.
I’ve been checking in a range of commits that change a lot of the fundamentals of how Panda is built. Anything in particular that is broken?
Well. See my last traceback (February 20), for one. I checked libpandaexpress and couldn’t find any particular change having caused this, so I assume it’s caused by some of the changes made to suit the new build fundamentals.
Ah, I didn’t see that message, apologies.
Certainly not “anyone and his dog” can commit and break something; only a handful of people have commit access. It would not be any different with SVN. We do plan on migrating to git or hg, which will help with this matter in some ways, but sometimes there simply are going to be big changes with the potential to break a lot of things. This was one of them.
In this case, the problem is that the new built/panda3d tree was not correctly transferred to the system on installation when it is building a .deb. An oversight in my testing procedure.
I’ve checked in a fix for the problem. Alternatively, you can manually install it by copying the built/panda3d directory to your Python dist-packages directory, as returned by “distutils.sysconfig.get_python_lib(1)”, something like:
sudo cp -r built/panda3d /usr/lib/python2.7/dist-packages(on some systems it is /usr/lib64 instead)
You will also need to do this:
sudo rm /usr/share/panda3d/panda3d.py*Checked out the most recent cvs.
Wouldn’t create .deb packages, due to the following traceback
A quick diff between the installpanda.py found in /makepanda and the one from my Frankenstein Panda build revealed the the following line missing at line number 129
oscmd("mkdir -m 0755 -p "+destdir+prefix+"/share/panda3d/direct")EDIT: Did anyone make an attempt at cross-compilation yet? I’d love to compile the engine for x64 Windows, preferably on the same server I do all my Linux builds on. I heard about performance penalties using MinGW, but those probably apply to the Windows “native” release only, right?
Sorry, I forgot to remove the line that wrote direct/init.py, I just checked in a fix that removes it.
Yes, I believe someone did successfully make a cross-compilation for Windows, though I recall it involved quite a bit of effort and hair-pulling.
Yes, I did port Panda3D to MinGW-w64 a few month ago and have been able to cross-compile from FreeBSD and Linux to Windows. However, I decided to code in C++ and dropped support for Python. I didn’t compare performance, yet, and hope that we can commit a patch for the port to the codebase, soon, probaby in the next few weeks.
You wouldn’t happen to have documented your work with MinGW-w64? I’m sure it would be an interesting read.