This caused too much trouble, also it's possible users run with
'release' in their CWD causing issues.
Developers can symlink "release/" to "bin/2.79".
There were two issues here actually:
* The hack to allow running Blender directly from the source directory
would just check for a 'release' directory, without actually ensuring it
is release dir from blender source tree, and not some other random
folder.
* GHOST_getSystemDir returns nothing for portable installations, now
we'll then check directly in the blender binary dir in that case.
This fix is more critical in 2.8 branch, where that system path is used
to retrieve new '3D' icons...
This adds the ability to switch between different application-configurations
without interfering with Blender's normal operation.
This commit doesn't include any templates,
so its mostly to allow collaboration for the Blender 101 project
and other custom configurations.
Application templates can be installed & selected from the file menu.
Other details:
- The `bl_app_template_utils` module handles template activation
(similar to `addon_utils`).
- The `bl_app_override` module is a general module
to assist scripts overriding parts of Blender in reversible way.
See docs:
https://docs.blender.org/manual/en/dev/advanced/app_templates.html
See patch: D2565
Python name could include ABI-flags after the version,
since checking for all combinations of ABI flags can expand into many possibilities,
take the executable name from the build system.
- BLI_current_working_dir's return value must be checked, since it may fail.
- BLI_current_working_dir now behaves like getcwd, where a too-small target will return failure.
- avoid buffer overrun with BLI_path_cwd, by taking a maxlen arg.
