In the 1.10.8 thirdparty packages, OpenCV is split into a lib folder and a lib-10.6 folder, so we should use the proper dylibs to still be able to target 10.6
We can target 10.9 (the minimum supported) even with the 11.1 SDK, so we should just check for whichever SDK is available, and always target 10.9 (or 11.0 when building for arm64 only, since arm64 requires 11.0 to begin with).
This also means that --universal will always add both x86_64 and arm64 to the build.
Besides use of --universal with --osxtarget 11, it's now also possible to create a fat build with ARM64 by using --osxtarget 10.9 --arch x86_64 --arch arm64 (it will use the 11.x SDK but target 10.9)
FMOD Ex is also being disabled when building against the 10.14 SDK or higher, because the necessary libstdc++.6.0.9.dylib is no longer being shipped. FMOD Ex, libRocket and Cg are all disabled on ARM64 (FMOD Ex and Cg don't have the binaries available, libRocket could theoretically be built but there's no point as there won't be an ARM64 build of Python 2.7, and besides, we've deprecated it anyway).
Fixes#1062
/O2 is more "aggressive" for speed optimization and recommended for release builds, /Ox can be useful for debugging.
Also remove flags implied by /O2
Closes#1016
The new CMake build system uses @rpath rather than @loader_path when
specifying a library's dependencies. Since rpaths are set by the
executable, we don't need to do any path manipulation to relocate the
libraries to a .app bundle like we do with @loader_path.
Fixes#913
This results in size savings for thirdparty libraries that are only used once, and a size increase for libraries used more than once (eg. OpenSSL). More importantly, it prevents conflicts with other versions of the libraries loaded by other Python modules, such as the version of OpenSSL that the hmac module uses.
We need to be careful to only apply this for packages that are either used once, used in a plug-in module, or if we don't need to pass thirdparty library structures across Panda library boundaries. For example, I haven't done this for Bullet, since the Bullet symbols need to be available through libpandabullet.so due to the fact that pandabullet contains calls to the Bullet libraries in the inline methods.
Fixes#851
These were probably added before makepanda gained the ability to automatically add dependencies of static libraries when linking statically.
They don't really do any harm--the linker will probably optimize these out automatically--but it's cleaner not to add unused dependencies.
We haven't needed this for a while since the direct tree is both Python 2 and 3 capable, and furthermore, Python 2.7 is EOL and will be dropped soon in Panda3D.
We no longer support Windows XP and so there is no point in defaulting to the old 7.1 SDK, which is hard to install. To target Vista, we can use the 8.1 SDK (+UCRT).
Our support was stuck on an ancient version that has not been available for a while. If we were to continue support it should be done around the new PhysX 5.0 API, not 2.8.4.
Starting with macOS 10.15, we can no longer install into /Developer/Panda3D due
to it not being one of the sanctioned writable directories. This commit changes
the default install location to /Library/Developer/Panda3D, which is the next
best place to put it (discussion on this can be found in #760).
To keep compatibility with those who may rely on the old location, some
postinstall scripts have been added that create symlinks to the new location
if running on 10.14 or older.
Fixes#760Closes#825
It doesn't seem like this setting is actually needed (because mayapath does the necessary set-up), but while it's set, we might as well set it to something more sensible.
These are not intended to be invoked by the user directly, so .exe wrappers do not need to be generated. maya2egg will find the _bin equivalent by looking for it next to the executable itself.
rdb
Daniel
kamgha
Mitchell Stokes
Donny Lawrence
Leandro (Cerberus1746) Benedet Garcia
LD