Remove fmake from the tree.

[imp]

Summary

Remove all vestiges of supporting building
the tree with it. Building the tree with fmake was deprecated in
FreeBSD 9.x with the plan to remove it in 10. Remove it as part of the
11 release cycle. Remove all support for building prior to 9.0 release.

[imp]

Fix a couple stragglers.

Updating D2829: Remove fmake from the tree. Remove all vestiges of supporting building

the tree with it. Building the tree with fmake was deprecated in
FreeBSD 9.x with the plan to remove it in 10. Remove it as part of the
11 release cycle. Remove all support for...

[bapt]

You might want to wait after 8 EOL (2 weeks as I'm writting this) or add in UPDATING a statement saying they can use bmake from ports on older version

[ngie]

Needs to be added to ObsoleteFiles.inc as well

Makefile

147–153

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/

Makefile.inc1

1237–1238

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

UPDATING

34–38

The version's wrong.

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

[brooks]

Looks basically good. I'd prefer the .error point to UPDATING, but the basic guard is probably fine.

[imp]

Simon has been busy, cull the stuff he's already done from my diff.

[ngie]

Thank you again for spearheading this!

Makefile

148

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".

UPDATING

64–68

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 :(.

share/mk/bsd.progs.mk

25–32 ↗

(On Diff #6217)

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

[imp]

We support 9.0 and newer. FreeBSD 8 is going EOL very shortly, and there's no point. It diverts project resources to pretend to support things we simply don't have the time to support.

Makefile

148

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.

Makefile.inc1

1237–1238

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.

UPDATING

64–68

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.

[ngie]

Makefile

148

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.

Makefile.inc1

1237–1238

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.

UPDATING

64–68

*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 .

[ngie]

Makefile

148

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

[imp]

Makefile

148

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.

Makefile.inc1

1237–1238

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.

[emaste]

Makefile.inc1

1237–1238

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?

1304

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

[imp]

Please see https://reviews.freebsd.org/D2840 for just removing fmake and doing nothing else. That's a more modest step. I'll revisit the rest when the dust from metamode is settled.

[emaste]

share/mk/src.opts.mk

182

Will need to regenerate src.conf.5 too

[imp]

I've committed part of this, and am punting on the rest. There was some pushback.