Linux build is too memory-aggressive on 16 GB hosts; parallelism should be configurable and conservative by default

[alexanderwwagner]

This issue is unique.

• I have used the search tool and did not find an issue describing my idea.

Your idea.

Description

The current Linux build path for DesktopEditors is too memory-aggressive for common developer hardware, especially notebooks with 16 GB RAM. On such systems, the build can consume nearly all available memory, trigger OOM conditions, or make the machine unresponsive.

This is not a correctness issue in the produced artifacts, but a build orchestration problem: the Linux Docker-based flow currently allows too much parallel work in memory-intensive stages and does not consistently provide a conservative default for local builds.

Observed problem

• Running the Linux build on a 16 GB notebook can exhaust available RAM.
• The host may become unstable or the build may be killed by OOM.
• Lowering concurrency is not consistently enforced across all relevant build stages.
• One stage forces full-CPU parallelism regardless of host memory constraints.

Expected behavior

• The Linux build should complete reliably on 16 GB systems.
• Parallelism should be explicitly controlled in memory-heavy stages.
• Hardcoded full-CPU parallelism should be replaced by a configurable limit.
• Default behavior should prioritize stability over speed for local builds.
• Manual override must remain possible for CI/high-memory hosts.

Technical notes

1. Parallelism is not uniformly controlled
   Some stages use implicit build parallelism, which is too aggressive on low-memory machines.

2. WASM stage is hardcoded to full CPU usage
   The WASM build path currently uses CPU-count based parallelism, which is unsafe for memory-constrained hosts.

3. Build orchestration can increase peak RAM
   A combined orchestration path can create avoidable memory spikes.

4. No host-aware default
   Developers currently have to discover and set safe values manually.

Proposed implementation

1. Use one explicit Linux build tuning knob for CMake/Ninja parallelism.
2. Apply the limit in all relevant CMake build stages.
3. Replace hardcoded full-CPU parallelism in WASM with a configurable limit.
4. Use a sequential local wrapper flow:
   • Build desktop-common first
   • Then build/package desktop-linux
5. Add conservative auto-tuning for local builds when no manual value is set:
   • About 1 job per 8 GiB available RAM
   • Minimum 1
   • Maximum CPU count
   • Optional conservative cap
6. Keep manual override behavior intact and highest priority.

Suggested PR split

1. Linux wrapper improvements

   • Sequential orchestration
   • Host-aware auto-tuning
   • Startup log of selected parallelism
   • README updates

2. Desktop native Docker build

   • Explicit parallel limit in CMake build invocation

3. Core and WASM Docker build

   • Remove hardcoded full-CPU parallelism
   • Explicit parallel limit in CMake build invocation

Suggested pull requests

#55

Euro-Office/core#121

Euro-Office/desktop-apps#34