foundationdb/packaging
Michael Stack 60d24dabcd
mako: gate build behind BUILD_MAKO cmake option (#13322)
* mako: gate build behind BUILD_MAKO cmake option

Two related changes:

1. mako had strip_debug_symbols(mako) (added in #13159) but no
   prepare_mako_install ALL target, so strip_only_mako never ran on a
   plain `ninja` build and packages/bin/mako was missing. As a result,
   `BUILD_MAKO=1 ./packaging/docker/build-images.sh` failed at "COPYING
   mako" — broken since #13159 landed.

2. The mako binary itself has been built unconditionally since 2019.
   It has no test consumers; the only out-of-tree consumer is the PGO
   generate_profile target. Match the spirit of #13159's opt-in docker
   pitch by gating the entire mako build behind a new BUILD_MAKO cmake
   option (default OFF). With -DBUILD_MAKO=ON, both bin/mako and
   packages/bin/mako are produced together.

build-images.sh no longer reads the BUILD_MAKO env var at all — it
auto-detects from packages/bin/mako presence. So the cmake option is
the single source of truth: configure with -DBUILD_MAKO=ON, mako gets
built and packaged into a docker image; configure without, no mako
anywhere. Existing `BUILD_MAKO=1 ./build-images.sh` invocations still
work iff the cmake side was also configured with the option.

The PGO generate_profile target now guards its mako dependency with
`if(TARGET mako)` so it still works without the option.

* mako: address PR review on BUILD_MAKO gate

Two small fixups from Copilot review:

1. cmake/FDBComponents.cmake — the comment claimed
   `BUILD_MAKO=1 ./packaging/docker/build-images.sh` was the opt-in
   path, but build-images.sh no longer reads the env var; it
   auto-detects packages/bin/mako. Updated the comment to match:
   opt in via -DBUILD_MAKO=ON, and build-images.sh picks up
   packages/bin/mako when present.

2. bindings/c/CMakeLists.txt — gate `prepare_mako_install ALL DEPENDS
   strip_only_mako` on `NOT GENERATE_DEBUG_PACKAGES` to match the
   convention used by fdbcli, fdbserver, fdbbackup, and fdbmonitor.
   Without this, mako gets stripped and packages/bin/mako is generated
   in debug-package builds, where every other binary takes the
   unstripped fdb_install(TARGETS ...) path instead.
2026-06-04 16:39:20 -07:00
..
deb Fixed the installation path for fdbmonitor and backup_agent (#2579) (#12236) 2025-08-26 13:45:14 -07:00
docker mako: gate build behind BUILD_MAKO cmake option (#13322) 2026-06-04 16:39:20 -07:00
msi XDB-494 fixed windows build #12630 (#12793) 2026-03-19 09:15:30 -07:00
multiversion Fixed the installation path for fdbmonitor and backup_agent (#12432) 2025-10-12 09:28:46 -07:00
osx Update macOS build instructions in README (#12788) 2026-03-18 15:52:01 -07:00
rpm Fixed the installation path for fdbmonitor and backup_agent (#2579) (#12236) 2025-08-26 13:45:14 -07:00
description Some more improvements to the build and preparations for packaging 2018-12-13 15:04:13 -08:00
fdb.cluster.cmake First version of working rpm packages 2018-12-13 15:55:31 -08:00
foundationdb.conf Fixed the installation path for fdbmonitor and backup_agent (#2579) (#12236) 2025-08-26 13:45:14 -07:00
foundationdb.ico Initial repository commit 2017-05-25 13:48:44 -07:00
make_public.py Update copyright years to 2013-2026 (#12653) 2026-01-22 10:49:41 -08:00