| git.druid.rocks | index | druid520 | mp | docs/ | reference/ | commands/ | hook.btft |
docs/reference/commands/hook.btft
[table class="topnav"]
[tr]
[td class="logotab"]mp[e]
[td][see name="index"]index[e][e]
[td][see name="guide/index"]guide[e][e]
[td][see name="reference/index"]reference[e][e]
[e]
[e]
[h1]mp hook[e]
[h2]synopsis[e]
[code]
$MP_HOOK <event-name>
[e]
[h2]description[e]
not really a user-facing command -- this is how a phase script fires a custom, port-author-chosen hook point mid-phase. every phase script gets [code]MP_HOOK[e] exported pointing at this command, so a phase script just runs [code]"$MP_HOOK" my-custom-step[e]. it reuses the exact same [code]run_hook()[e] machinery every built-in [code]pre_[e]/[code]post_<phase>[e] boundary already goes through: [code]hook_my-custom-step=[e] in mp.conf, [code]HOOKS_DIR/my-custom-step/*[e], and that directory's own [code]hooks.conf[e] pipeline all just work, with zero extra code anywhere.
the event name must look like a plain identifier (letters/digits/underscore/hyphen, starting with a letter) and can't collide with one of the RESERVED built-in lifecycle names ([code]pre_fetch[e], [code]post_install[e], [code]on_fail[e], and so on) -- firing one of those here would re-trigger whatever's configured for that real lifecycle boundary a second time, mid-phase, with no indication anything unusual happened; rejected outright rather than silently double-firing something that may not be idempotent.
when the calling phase is itself running inside a sysroot scope, [code]MP_HOOK[e] is fired with the right [code]--sysroot=[e] automatically (via [code]MP_SYSROOT[e], also exported to every phase script) -- without this, a custom hook fired from a sysroot-scoped phase would silently resolve against the DEFAULT root's mp.conf/HOOKS_DIR instead of the sysroot's own.
[h2]examples[e]
a phase script, firing a custom event other tooling can hook into:
[code]
post_build:
"$MP_HOOK" my-custom-step
[e]
[h2]see also[e]
[see name="reference/hooks"]reference/hooks[e] (every pre_/post_ boundary, the three ways to hook one, custom event firing in full).