Problem
When a user needs to replace a recipe that pgxntool generates (e.g. the versioned SQL file rule from control.mk), they must define their own recipe for the same target. GNU Make responds with:
Makefile:N: warning: overriding recipe for target 'sql/ext--1.2.3.sql'
control.mk:7: warning: ignoring old recipe for target 'sql/ext--1.2.3.sql'
The warnings are harmless — the user's recipe wins — but they're noisy and unavoidable. There is currently no supported way to suppress pgxntool's default recipe for a target so that a user can provide their own cleanly.
Concrete case
cat_tools uses .sql.in template files with SED-based version-conditional substitutions. The default control.mk recipe (which simply cats sql/cat_tools.sql) is wrong for this use case, so the Makefile overrides it — and gets the warnings on every make invocation.
Considered approaches
Two approaches stand out:
Approach A (immediate fix): In control.mk.sh, wrap the generated recipe in an ifndef guard keyed on a per-extension variable, and emit the prerequisites unconditionally:
# Always emitted — establishes prerequisites
$(EXTENSION_cat_tools_VERSION_FILE): sql/cat_tools.sql cat_tools.control
# Conditionally emitted — default recipe
ifndef PGXNTOOL_OVERRIDE_VERSION_RULE_cat_tools
$(EXTENSION_cat_tools_VERSION_FILE):
@echo '/* DO NOT EDIT */' > $@
@cat sql/cat_tools.sql >> $@
endif
User sets PGXNTOOL_OVERRIDE_VERSION_RULE_cat_tools = 1 before include pgxntool/base.mk and defines their own recipe freely.
Approach B (longer-term refactor): Move all rule generation out of control.mk.sh into base.mk using define/$(eval $(call ...)) — the same pattern already used for ASCIIDOC_template. control.mk becomes purely declarative (variables only). The ifndef guard lives in base.mk where it can be maintained and extended in one place.
Approach B is the better long-term architecture (separates declarative metadata from build logic) but is a larger change. Approach A is a safe incremental fix.
Notes
- This is not limited to the version file rule — any pgxntool-generated recipe has the same problem if a user wants to replace it.
PGXNTOOL_ENABLE_* flags are an acceptable mechanism for disabling entire features; this issue is specifically about replacing individual recipes within a feature that is otherwise kept enabled.- Double-colon rules are not a viable solution here (would require both sides to use
:: and would run both recipes).
Problem
When a user needs to replace a recipe that pgxntool generates (e.g. the versioned SQL file rule from
control.mk), they must define their own recipe for the same target. GNU Make responds with:The warnings are harmless — the user's recipe wins — but they're noisy and unavoidable. There is currently no supported way to suppress pgxntool's default recipe for a target so that a user can provide their own cleanly.
Concrete case
cat_toolsuses.sql.intemplate files with SED-based version-conditional substitutions. The defaultcontrol.mkrecipe (which simply catssql/cat_tools.sql) is wrong for this use case, so the Makefile overrides it — and gets the warnings on everymakeinvocation.Considered approaches
Two approaches stand out:
Approach A (immediate fix): In
control.mk.sh, wrap the generated recipe in anifndefguard keyed on a per-extension variable, and emit the prerequisites unconditionally:User sets
PGXNTOOL_OVERRIDE_VERSION_RULE_cat_tools = 1beforeinclude pgxntool/base.mkand defines their own recipe freely.Approach B (longer-term refactor): Move all rule generation out of
control.mk.shintobase.mkusingdefine/$(eval $(call ...))— the same pattern already used forASCIIDOC_template.control.mkbecomes purely declarative (variables only). Theifndefguard lives inbase.mkwhere it can be maintained and extended in one place.Approach B is the better long-term architecture (separates declarative metadata from build logic) but is a larger change. Approach A is a safe incremental fix.
Notes
PGXNTOOL_ENABLE_*flags are an acceptable mechanism for disabling entire features; this issue is specifically about replacing individual recipes within a feature that is otherwise kept enabled.::and would run both recipes).