Support"one-click" deployment to Windows, macOS, Linux, Web, and Android. A user should be able to build for all platforms from one machine.
Be able to build installers and portable builds
Build settings(e.g., name, version, author, etc.) need to be able to be put under version control(e.g., config files)
Keep impact on Panda3D releases minimal
Use optimized builds for deployed binaries/libs for space and performance
Nice to have
Provide a mechanism to keep games up to date(only needed when platforms like Steam are not being used)
Current Systems
pdeploy/ppackage
Pros:
Can deploy to all available platforms from one platform/machine
Can be used to update games
Build settings can be defined in a pdef file
Cons:
Huge maintenance burden having to build new runtime and rtdist builds on each release
Very complicated for new users and for using custom Panda3D builds(including Python3 builds)
Part of direct
Any Python modules have to be specially packaged
pfreeze
Pros:
Easier to use for Web/Android than pdeploy
Only packs the modules that are actually being used
Cons:
Can only build for non-native platforms if a proper cross-compiling toolchain is available(e.g., to platforms like Web or Android). In other words, no simple path to"one-click" deployment to all available platforms.
Cannot store resources in the executable itself, only Python code
Ideas to Investigate
Using whls to manage binaries/dependencies
Salvaging code from Packager and FreezeTool to figure out dependencies of dynamic libraries
Integrating the build tools with distutils to provide a familiar experience for Python users
Creating a custom launcher stub that can load non-frozen Python modules via the frozenmodule mechanism
Append frozen bytecode to the end of the stub and always load this bytecode.
This custom stub could be built around the FreezeTool core to allow us to reuse most of the relevant logic.
Goals
Current Systems
Ideas to Investigate
Current Implementation