Add Meson build system for all platforms

[s-celles]

Summary

• Add a complete Meson build system (meson.build, meson_options.txt) as an alternative to CMake/Gradle, supporting all existing target platforms
• Add 12 cross-compilation files (cross/) for Android (4 ABIs), iOS (3 variants), Mac Catalyst (2 architectures), Windows (MinGW x86_64), Emscripten WASM, and Linux ARM
• Add helper scripts: build-all.sh (automated multi-platform build), build-xcframework.sh (iOS xcframework assembly), embed-wasm.sh (WASM base64 post-processing)
• Add README-BUILD-WITH-MESON.md with build instructions for all targets

Validated Targets

All 13 build targets pass from a macOS host:

Platform	Variants	Outputs
macOS (native)	desktop	libgiac.a, minigiac, libjavagiac.dylib
Android	arm, arm64, x86, x86_64	libgiac.a, libjavagiac.so
iOS	arm64, sim-arm64, sim-x86_64	libgiac.a, libsimpleinterface.a
Mac Catalyst	arm64, x86_64	libgiac.a, libsimpleinterface.a
Windows	x86_64 (MinGW cross)	libgiac.a, libjavagiac.dll
Emscripten	wasm32	giacggb.wasm, giac.wasm.js

Design Decisions

• Uses prebuilt static GMP/MPFR from src/jni/prebuilt/ for cross-builds, system libraries for native builds
• Preprocessor defines follow build.gradle (authoritative) rather than CMake
• Uses vendored JDK headers from src/jni/jdkHeaders/ instead of requiring Java as a Meson project language
• Coexists with existing CMake and Gradle build systems — no existing files are modified (except .gitignore)

Test plan

• Native desktop: echo '1+1' | ./builddir/minigiac outputs 2
• Android: all 4 ABIs produce ELF shared libraries
• iOS/Catalyst: all 5 variants produce static libraries
• Windows: produces PE32+ DLL
• Emscripten: produces WASM binary + embedded JS
• ./scripts/build-all.sh runs all targets with 13/13 passing

[s-celles]

Be aware that only execution on native desktop (macOS) and Webassembly have been tested (on a very basic example ie 1+1)

---

Some AI thoughts about Meson...

Meson Build System

Meson is a modern, open-source build system designed to be fast, user-friendly, and correct. It generates build files for a backend (typically Ninja), rather than executing builds itself. It's written in Python but produces highly optimized build configurations.

Key characteristics

Meson emphasizes speed (both configuration and compilation), a clean and readable syntax (its DSL is deliberately not Turing-complete to keep build definitions simple), and strong out-of-the-box defaults like warning flags, LTO, and unity builds.

Why it's particularly interesting for multi-arch cross-compilation (like GIAC)

For a project like GIAC — a computer algebra library that needs to compile across many architectures (x86_64, ARM, RISC-V, WebAssembly, etc.) — Meson brings several compelling advantages:

First-class cross-compilation support. Unlike autotools or CMake, cross-compilation in Meson isn't an afterthought. You define a simple "cross file" (an INI-like text file) that specifies the target architecture's compiler, linker, system properties (endianness, pointer size, etc.), and any pkg-config paths. Once that file exists, a cross build is invoked with a single flag: meson setup builddir --cross-file arm64-linux.txt. No need to fight with toolchain files or arcane environment variables.

Strict separation of build and host. Meson clearly distinguishes between the build machine (where compilation runs) and the host machine (where the binary will run), and optionally the target machine. This makes it natural to handle scenarios where you compile GIAC on an x86_64 workstation but target an embedded ARM board.

Reproducible and hermetic builds. Because Meson's language is intentionally limited (no arbitrary shell commands in the build definition), builds are more deterministic. This matters when you're building the same codebase for 5+ architectures and need confidence that differences in output come only from the toolchain, not from build system quirks.

Dependency handling. Meson integrates well with pkg-config and wraps (its built-in dependency vendoring system). For GIAC, which depends on GMP, MPFR, and potentially other math libraries, you can define fallback subprojects per architecture without contaminating the main build logic.

Fast incremental rebuilds. Since GIAC is a large C++ codebase, the Ninja backend that Meson targets provides excellent incremental build performance — much faster than Make-based systems for large projects with many translation units.

Unity builds are natively supported, which can dramatically reduce compile times for large C++ projects like GIAC by combining source files before compilation, reducing redundant header parsing.

In short, Meson removes much of the friction traditionally associated with cross-compilation. Where autotools requires deep expertise and CMake toolchain files can become complex and fragile, Meson's cross files are straightforward and self-contained — making it a natural fit for a project like GIAC that aims to be portable across many platforms.

---

Several major and well-known projects have adopted Meson. Here are some notable ones:

System-level and foundational projects:

• GNOME — one of the earliest large-scale adopters; virtually the entire GNOME stack (GTK, GLib, Pango, GStreamer, etc.) has migrated from autotools to Meson
• systemd — the Linux init system
• Mesa — the open-source OpenGL/Vulkan graphics driver stack, a massive C/C++ codebase
• Wayland and Weston
• PipeWire — the modern audio/video server replacing PulseAudio

Multimedia:

• GStreamer — multimedia framework
• QEMU — the processor emulator/virtualizer migrated from Make to Meson
• X.Org components

Libraries and tools:

• json-glib, libsoup, NetworkManager
• Frida — the dynamic instrumentation toolkit
• sysprof, Flatpak

Language ecosystems:

• Hotspot / DPDK — high-performance networking
• PostgreSQL has added Meson as an alternative build system alongside autotools

Other:

• Budgie Desktop, Enlightenment, Sway (Wayland compositor)
• Many Freedesktop.org projects (fontconfig, dbus, etc.)

The trend is clear: projects that were historically tied to autotools — especially in the Linux/GNOME/Freedesktop ecosystem — have been steadily migrating to Meson. Mesa and QEMU are perhaps the most impressive examples, given their sheer size and complexity, demonstrating that Meson scales well for large, multi-platform, multi-architecture C/C++ codebases — which is exactly the profile GIAC fits into.

---

Meson is fully compatible with Windows. This is actually one of its major strengths compared to autotools (which is notoriously painful on Windows).

Specifically, on Windows, Meson supports:

Native Windows compilers: MSVC (Visual Studio), Clang-cl, and MinGW/GCC. It automatically detects the available compiler and adapts accordingly.

Backends: Ninja (the most common) but also direct generation of Visual Studio projects (meson setup builddir --backend=vs), which allows Windows developers to work in their usual IDE.

Cross-compilation from/to Windows: you can cross-compile to Windows from Linux (using MinGW), or from Windows to other targets.

Installation is straightforward: either via pip install meson, the official .msi installer, or through package managers like Chocolatey or Scoop.

For a project like GIAC, this is a significant advantage: autotools is historically very poorly suited to Windows (you typically need to go through MSYS2/Cygwin, which adds a layer of complexity). With Meson, you can natively target Windows with MSVC without those contortions, while keeping the exact same meson.build file as for Linux or macOS. One single build system, all platforms.

[zbynek]

@s-celles thanks for working on this.

This repository is a shared effort of Bernad Parisse, the maintainer of Giac, who authors the actual code, and the GeoGebra team who keep the build files up-to-date with the goal of providing Giac library for all the platforms that GeoGebra runs on. To make use of your changes GeoGebra team would have to test them, update our build machines to make sure Meson install requirements are met, update the pipeline definition etc., at the moment I don't think we have the capacity to work on that. I can ask Bernard if he sees a use of this PR for non-GeoGebra builds.