forked from aki/docker-aseprite-linux
2 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| b0479bfbf4 |
feat: Implement Flatpak build system using flatpak-builder in Docker
This commit replaces the previous multi-distribution Docker build system with a unified Flatpak build process executed inside a Docker container. This is the intended final architecture for building Aseprite bundles.
**Key Changes:**
* **Transition to Flatpak:** The core build logic now uses `flatpak-builder` and a Flatpak manifest (`com.aseprite.Aseprite.yaml`) to compile Aseprite and its dependencies against a standard Flatpak SDK runtime.
* **Unified Docker Environment:** Replaced distribution-specific `Dockerfile.<distro>` files with a single `Dockerfile` that sets up a consistent environment containing `flatpak-builder` and the necessary Flatpak SDK.
* **Simplified Makefile:** Removed OS detection logic and multi-distro targets. The Makefile now orchestrates:
1. Running `prepare_sources.sh` on the host (still responsible for reliable source fetching/syncing).
2. Building the single Flatpak builder Docker image.
3. Running `flatpak-builder` inside a *privileged* container (required for `flatpak-builder` sandboxing) to perform the actual build.
4. Running `flatpak build-bundle` inside the container.
5. Extracting the final `.flatpak` bundle from the container to `./target/aseprite.flatpak`.
* **Updated .gitignore:** Added `build/`, `target/`, `*.flatpak`, and `*.log` to ignore Flatpak build directories, output bundles, and logs. Removed the old `dependencies` ignore pattern.
* **Prepare Sources Update:** Modified `prepare_sources.sh` to explicitly initialize `depot_tools` on the host, as this is required before sources are copied into the Flatpak build environment for `gn` usage.
* **Removal of Old Files:** Deleted `Dockerfile.<distro>`, `Dockerfile.debian`, `Dockerfile.fedora`, `Dockerfile.arch` (multi-distro Dockerfiles), and the original generic `Dockerfile` and `docker-compose.yml`.
**Rationale:**
This refactor moves to the planned final architecture. Building within a Flatpak SDK provides a highly consistent environment independent of the host Linux distribution. The output is a portable `.flatpak` bundle, simplifying distribution and runtime compatibility compared to dynamically linking against varied host libraries. While `prepare_sources.sh` on the host still handles the initial (and potentially rate-limited) source fetching, the subsequent build process is significantly standardized and more reliable.
This architecture is now the **forward-maintained** build method.
|
|||
| d12f0bdf88 |
refactor: Overhaul build system for reliability and future portability
This commit introduces a major refactoring of the Aseprite build process. It replaces the previous fragile system (prone to dependency fetching failures) with an interim multi-distribution Docker approach, paving the way for a future transition to Flatpak.
**Problems Addressed:**
* **Build Fragility & Dependency Fetching:** The prior method, compiling dependencies from source within a generic container, frequently failed due to network issues and rate limiting during source/sub-dependency acquisition (e.g., Skia's `git-sync-deps`), often late in the process. Source state inconsistencies could also cause failures.
* **Complexity of Full Source Builds:** Managing the compilation of the entire dependency tree from source was complex.
**New Architecture & Rationale:**
* **Host-Side Source Preparation (`prepare_sources.sh`):** Isolates the problematic source fetching and state management to a host-side script run *before* the main build. Key features:
* Handles cloning/updating core sources (`depot_tools`, Skia, Aseprite).
* Runs Skia `git-sync-deps` with **robust retry logic** to specifically address rate limit errors.
* Includes an `--check-integrity` flag which performs **aggressive checks and resets** (fetching, checking out specific tags/commits, resetting state) to ensure the local source directories precisely match the required state for the build, potentially involving significant network activity.
* **Distribution-Specific Builds (Interim Step):** Introduced `Dockerfile.arch`, `Dockerfile.debian`, `Dockerfile.fedora`. These use native package managers to install pre-built *common* development libraries within the container, simplifying the Docker build stage itself. Requires OS detection or manual selection (`TARGET_DISTRO`).
* **Clear Build Stages (Makefile):** Orchestrates source preparation, image building, and final binary extraction (`docker cp` to `./output/bin`).
* **Cleaned Structure:** Removed obsolete scripts/files (`compile.sh`, generic `Dockerfile`, `docker-compose.yml`) and updated `.gitignore`.
**Limitations & Future Direction (Flatpak):**
* **Fetching Challenges Persist:** While reliability is improved by isolating source prep and adding retries/integrity checks in `prepare_sources.sh`, the core challenge of potential rate limits or network issues during this initial step remains.
* **Flatpak for Portability:** The current multi-distro Docker setup is an **intermediate solution**. The ultimate goal and **forward-maintained approach** is migrating to **Flatpak (`flatpak-builder`)**. Flatpak will provide a **unified, distribution-agnostic build environment** using standard runtimes and produce a **portable `.flatpak` bundle**, eliminating the need for OS detection/separate Dockerfiles and ensuring consistent builds *after* sources are successfully prepared.
|
