This should have been credited as “reported by: Daniel Hodson <daniel@elttam.com>”

The text you removed from the manual page explains why there are two separate options for this...

Thanks. I wonder if the performance impact is measurable...

The manual page already has two entire paragraphs about the past and present differences between shutdown and reboot, and they are not equivalent.

Use “fast” prefix, not -f flag, to choose modes.

In D54117#1236374, @imp wrote:

This is what I've wanted to do for some time now. I didn't look closely enough, but so long as fastboot gives us the current behavior, (aka the -f behavior), I'm good with all this.

In D52011#1236230, @imp wrote:

A common pattern is for there to be one build tree, with lots of options turned on, and then lots of installs from that tree with differing sets of options. This is done to speed the build. If suddenly world gets cleaned unconditionally, without my control, that could be very bad.

Add DEPEND_CLEANUP option

You are probably pulling from a mirror (as the committer's guide recommends) and the mirrors are sick at the moment. This should fix it:

git remote set-url freebsd git@gitrepo.freebsd.org:ports.git
git pull --rebase
git push

update

• Make “Cleaning ...” messages unconditional as requested by @markj.

Don't worry about depend-cleanup.sh, D52011 will take care of it.

I didn't look at what lang/go-devel actually contains, I just went by GO_VALID_VERSIONS and the existing logic which seems to suggest that lang/go-devel currently offers 1.26. I don't care if we remove it, but I suggest we settle this first, and let @ashish have a say.

In D54104#1236117, @fuz wrote:

Could we yoink the logic from python.mk for this?

@sjg can you please confirm that this change does not break dirdeps mode? It doesn't make any difference in the common case in stock FreeBSD, but it fixes an issue downstream.

local and indentation

I've been traveling and haven't yet had time to review the latest changes, but last I looked it was moving in the right direction. Just give me a few more days.

So I checked and the preprocessor _does_ do short-circuit evaluation of boolean expressions, so this shouldn't be necessary, yet gcc complains:

In D53980#1233312, @imp wrote:

Oh that's what you meant. Why wouldn't it be in scope?