Here's something I currently do to ports-framework changes I need on the
machine I work on from actual port changes that ought to be committed.
The way it works is that I just fill
/usr/ports/category/port/site-local-config.mk with someting like
USE_CCACHE = Yes
or
DEBUG_PACKAGES = # empty, machine too slow/not enough space
so I can easily carry required changes without mixing them up in
Makefile with other changes.
If the file does not exist nothing happens.
If if exists it is sourced after Makefile (obviously) but any
bsd.port.mk logic uses variables, thus site-local-config.mk is free to
change every aspect of the port.
What do others think?
Is this too much of a special use-case to be supported?
Too much shoot-yourself-in-the-foot potential?
If porters pollute this file and commit stuff that depends on the site
local config so that bulk builds fail we certainly have a net-loss, but
I somewhat trust committers to take care of this.
Afterall, it's similar to /etc/mk.conf already where local configs do
effect builds and yet it seems fine.
Index: bsd.port.mk
===================================================================
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1576
diff -u -p -r1.1576 bsd.port.mk
--- bsd.port.mk 6 Jul 2022 09:30:41 -0000 1.1576
+++ bsd.port.mk 11 Jul 2022 11:22:41 -0000
@@ -44,6 +44,11 @@
#
#
+# Include site-local port-specific configuration iff it exists.
+#
+-include site-local-config.mk
+
+#
# tests and variable definitions come first, THEN targets
#
.for forbidden in FLAVOR SUBPACKAGE SUBDIR SUBDIRLIST
