pc-heini
280238bbd7
With the non-editable o3de install, the package lives in the per-user venv, so manifest.get_this_engine_path() (which walks up from the package __file__) resolved into the venv and engine.json wasn't found -> "Failed to get engine info" / "Failed to initialize". O3DE has a built-in override for this immutable-install case: when SNAP and SNAP_BUILD are set, get_this_engine_path returns "$SNAP/$SNAP_BUILD". The wrapper now sets them to the engine root. Verified by launching with these vars set: the Project Manager opens with no engine.json errors. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
66 lines
3.0 KiB
Bash
Executable File
66 lines
3.0 KiB
Bash
Executable File
#!/bin/sh
|
|
# Launcher for the O3DE Project Manager inside the Flatpak sandbox.
|
|
#
|
|
# The Debian package installs O3DE under /opt/O3DE/<version>/, which becomes
|
|
# /app/opt/O3DE/<version>/ inside the Flatpak. The version directory name
|
|
# changes with every release, so we discover the executable at runtime instead
|
|
# of hard-coding a path.
|
|
set -eu
|
|
|
|
O3DE_ROOT=/app/opt/O3DE
|
|
|
|
# Bundled shared libraries that ship inside the .deb.
|
|
export LD_LIBRARY_PATH="/app/lib:${O3DE_ROOT}/lib:${LD_LIBRARY_PATH:-}"
|
|
|
|
# Locate the Project Manager executable ("o3de").
|
|
O3DE_BIN=$(find "$O3DE_ROOT" -type f -name o3de -path '*bin/Linux*' 2>/dev/null | head -n 1)
|
|
if [ -z "$O3DE_BIN" ]; then
|
|
O3DE_BIN=$(find "$O3DE_ROOT" -type f -executable -name o3de 2>/dev/null | head -n 1)
|
|
fi
|
|
|
|
if [ -z "$O3DE_BIN" ]; then
|
|
echo "error: O3DE executable not found under $O3DE_ROOT" >&2
|
|
echo " (the .deb layout may have changed)" >&2
|
|
exit 1
|
|
fi
|
|
|
|
# Make libraries that sit next to the binary discoverable too.
|
|
export LD_LIBRARY_PATH="$(dirname "$O3DE_BIN"):${LD_LIBRARY_PATH}"
|
|
|
|
# Bootstrap O3DE's per-user Python venv if needed. The Project Manager GUI does
|
|
# NOT set this up itself - it just errors out ("Missing python venv file ...") if
|
|
# the venv is absent. So we ensure it here. python.sh exits non-zero when the
|
|
# venv for this engine is missing/stale; get_python.sh then downloads Python,
|
|
# creates the venv (~/.o3de/Python, writable) and installs the 'o3de' CLI from
|
|
# the prebuilt sdist. It is idempotent and self-healing (recreates a broken venv
|
|
# with --clear). cmake, needed for the engine-id calc, ships in the Sdk runtime.
|
|
PYTHON_SH=$(find "$O3DE_ROOT" -type f -path '*/python/python.sh' 2>/dev/null | head -n 1)
|
|
GET_PYTHON=$(find "$O3DE_ROOT" -type f -path '*/python/get_python.sh' 2>/dev/null | head -n 1)
|
|
if [ -n "$GET_PYTHON" ]; then
|
|
ENGINE_ROOT=$(dirname "$(dirname "$GET_PYTHON")")
|
|
|
|
# O3DE's Python derives the engine path from the o3de package's __file__. That
|
|
# breaks with our non-editable install (the package lives in the per-user venv,
|
|
# not the engine tree), so engine.json is looked for under the venv and not
|
|
# found ("Failed to get engine info"). O3DE has a built-in override for exactly
|
|
# this immutable-install case: if SNAP and SNAP_BUILD are set, manifest.py's
|
|
# get_this_engine_path() returns "$SNAP/$SNAP_BUILD". Point them at the engine
|
|
# root. (Verified nothing else in O3DE - Python or the C++ binaries - reads
|
|
# these two vars, so there are no snap-specific side effects.)
|
|
SNAP=$(dirname "$ENGINE_ROOT")
|
|
SNAP_BUILD=$(basename "$ENGINE_ROOT")
|
|
export SNAP SNAP_BUILD
|
|
|
|
# Bootstrap the per-user Python venv if needed (the GUI doesn't do it itself).
|
|
if ! "$PYTHON_SH" --version >/dev/null 2>&1; then
|
|
echo "O3DE: setting up the per-user Python environment." >&2
|
|
echo "O3DE: first launch downloads Python and can take several minutes..." >&2
|
|
if ! "$GET_PYTHON"; then
|
|
echo "error: O3DE Python setup failed (see the log above)." >&2
|
|
exit 1
|
|
fi
|
|
fi
|
|
fi
|
|
|
|
exec "$O3DE_BIN" "$@"
|