pgxntool/base.mk has no include guard. If it is included more than once in a single make run, every target it defines gets redefined, producing overriding-recipe and ignoring-old-recipe warnings/errors.
This blocks a useful pattern: keeping an extension build configuration in its own .mk module that itself does include pgxntool/base.mk, so the module is a self-contained entry point and can guarantee the ordering of its DATA += additions relative to base.mk. It is compounded by setup.sh, which writes the base.mk include line into the extension Makefile via safecreate -- a module include plus the Makefile include then become a double inclusion.
Request: wrap base.mk contents in an ifndef/endif guard so double inclusion is harmless and extensions can safely include it from their own .mk files.
Context: encountered while refactoring the cat_tools versioned-SQL machinery into a sql.mk module -- https://github.com/Postgres-Extensions/cat_tools
pgxntool/base.mk has no include guard. If it is included more than once in a single make run, every target it defines gets redefined, producing overriding-recipe and ignoring-old-recipe warnings/errors.
This blocks a useful pattern: keeping an extension build configuration in its own .mk module that itself does include pgxntool/base.mk, so the module is a self-contained entry point and can guarantee the ordering of its DATA += additions relative to base.mk. It is compounded by setup.sh, which writes the base.mk include line into the extension Makefile via safecreate -- a module include plus the Makefile include then become a double inclusion.
Request: wrap base.mk contents in an ifndef/endif guard so double inclusion is harmless and extensions can safely include it from their own .mk files.
Context: encountered while refactoring the cat_tools versioned-SQL machinery into a sql.mk module -- https://github.com/Postgres-Extensions/cat_tools