On 2022/07/11 11:33, Klemens Nanni wrote: > 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?
Looks like you can add the -include line to /etc/mk.conf locally without touching bsd.port.mk, would it make more sense to do that or is that in the wrong place for some variables? > 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. I think the main risk would be from people accidentally doing a commit which adds a site-local-config.mk file to the repo. Not that bad a risk. > 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 >
