Skip to main content

Product Builds

Morph exposes a morph build-product command that targets desktop-style distributables: bundle logic (often a .vcon payload), a small native “nucleus” host, optional installer/updater settings, and platform resources. The public contract lives in include/morphc/cli/ProductBuilder.h and ProductSettings.cpp; orchestration is wired from cmdBuildProduct in Cmd_Build.cpp.

morph build-product --platform <target> [--compiler <path>] [--no-installer] [--no-updater] [--verbose]

--platform must match the product pipeline’s platform id (the same family of ids used for native packaging, e.g. host IDs like windows_x64 or whatever your build manifest maps from labels such as Windows).

What the pipeline is for​

At a high level, the product APIs are built around:

  1. VCON payload — project is compiled into a container suitable for the nucleus runtime (embedVconInBinary / related helpers in ProductBuilder.h).
  2. Nucleus binary — minimal native runtime for the selected platform, optionally embedding the .vcon.
  3. Branding / version resources — on the Windows host, ResourceCompiler.cpp may invoke windres to build VERSIONINFO and an icon from paths in .productsettings.
  4. Installer / updater — toggled via .productsettings (installer_*, update_*, uninstaller_* keys).

Exact sequencing (incrementing versions, manifest filenames, directory layout under output_dir) depends on the linked product-builder implementation for your toolchain build. Treat .productsettings keys and parseProductBuildArgs / buildProduct signatures as the stable reference.

Configuration (.productsettings)​

morph new generates this file beside morph.toml. Keys are parsed in src/cli/ProductSettings.cpp (INI-style key = value).

Identity & output​

# ── Identity ──
product_name = "My Application"
product_version = "1.0.0"
product_build_version = 1
product_publisher = "Publisher Name"
product_description = "A Morph application"
product_website = "https://example.com"

# ── Branding ──
# Per-platform icons: suffix after "icon." must match the platform id used
# when resolving icons (see ResourceCompiler / platformIcons map).
icon.windows_x64 = "assets/icon.ico"
icon.linux_x64 = "assets/icon.png"
icon.macos_arm64 = "assets/icon.icns"
splash_image = ""

# ── Output ──
output_name = "MyApp"
output_dir = "build/product"

Important: Icons use icon.<platformId>, not icon_windows. Use the same platform id strings your product/resource pipeline expects (often windows_x64, linux_x64, macos_arm64, matching MORPHLANG_ACTIVE_HOST_PLATFORM_ID style ids).

Optional blocks parsed by the same file include installer (installer_enabled, installer_style, shortcut flags, file_associations, …), update (update_enabled, update_url, …), and uninstaller settings.

Build version​

product_build_version is an integer read from and rewritten via saveProductSettings when tooling updates the file. Whether every successful build-product auto-increments it depends on the product-builder implementation you link; do not rely on docs alone—inspect the produced .productsettings after a build.

Native resources (Windows host)​

When build-product runs resource compilation on the current Windows target, runResourceCompiler calls into windres (ResourceCompiler.cpp). Ensure MinGW windres (or equivalent) is on PATH if you use icons or version resources.

Next Steps​