I was going to say "You must build with bmake; please see UPDATING for more details" -- especially because bmake wasn't available until 9.3:

https://svnweb.freebsd.org/base/release/9.2.0/usr.bin/ vs
https://svnweb.freebsd.org/base/release/9.3.0/usr.bin/

It wasn't available in 10.0 either:

https://svnweb.freebsd.org/base/release/10.0.0/usr.bin/ vs
https://svnweb.freebsd.org/base/release/10.1.0/usr.bin/

This is too late. The check really should have been in ./Makefile to begin with.

The version's wrong.

You have to upgrade from 9.3-RELEASE/10.1-RELEASE at least. Please see my comment above.

Please make UPDATING the single-point of info and say something like "fmake's no longer supported with FreeBSD; please see UPDATING for more details".

This is still incorrect version wise and this should contain all of the information required to get the end-user on the right path to building again.

I don't care about $work; we're [relatively] ok with our build jails now (it took a while to get here, but we're here now). Craig's concern however was valid about people being lazy with build systems, i.e. building with make on the host instead of having special versions of make (especially the FreeNAS crowd -- oh nelly). I want to avoid emails from random users about not being able to build on 8-STABLE anymore or earlier versions of 9.x or 10.0 -- cause that stuff happens from time to time (especially when they discover that FreeBSD has a new sexy feature that they want to use and decide to upgrade the base OS). Plus, it's more annoying for people who are non-devs (sysads) to figure out what's going on when trying to do upgrades :(.

This shouldn't be required now. I think Simon removed it

No. There's nothing in UPDATING that's actually useful. This message would not be helped by making that reference. There's no actual additional information.

This check has been here since ~forever. It can't be checked in Makefile, or didn't used to be able to, due to ordering issues.

That's absolutely correct version wise. FreeBSD 9.0 Release is the oldest version we support. We do not support 8.x in a way that will give people a useful and consistent experience. Pretending otherwise when there's no wood behind the spear is foolish.

We support 9.0 and newer.

I do need a quick note pointing to installing bmake for older versions though.

I disagree. UPDATING is extremely helpful. The fact that it's not being used to its fullest nowadays is sad -- especially because it's useful when quantifying to bosses who aren't tech savvy or sysads who aren't technical. It's annoying having to go back through commit logs looking for things (especially when you have to tie together git and svn commit logs). I've had to do this before for pjdfstest to backport pjdfstest to 7.x (for example) and it was a royal PITA.

Fair enough. Thanks for updating the version though... it would be nice if this was moved though, but we can do it in another commit.

*ducks to avoid flying fruit* Technically, it's 9.3, right (https://www.freebsd.org/security/unsupported.html)?

Joking aside, I understand what you mean now that I found the webpage; 8.4's going to be EOL by the end of the month: https://www.freebsd.org/security/index.html#sup .

sysads who aren't technical -> sysads who aren't devs

All I'm putting in the UPDATING entry is 'install this port'. That's what's in the message. There's nothing to be gained by having the extra verbage in the message itself. Nothing is more useless than getting a message, being told to see something else only to have that something else tell you nothing more. And there's very little that can actually be put into the updating entry that would help that.

No, it wouldn't be nice to move it. That's absolutely the wrong thing to do. As it is now, you can do many things that don't go through 'legacy' stage. If you move it you could do nothing. This should never be moved.

Upgrades from 8.x are already broken today, are they not?

Maybe we should go ahead with the boostrapping changes in a separate commit now, followed by the actual fmake removal itself after 8.x EOL?

This should be completely removed, should it not? If BOOTSTRAPPING is >= 900044 we have a good awk?

Will need to regenerate src.conf.5 too