Ports approved

Technically seems fine.
Feels like a POLA issue though. If I happened to have some package installed then buildworld behaved differently.
Maybe CROSS_TOOLCHAIN=yes or CROSS_TOOLCHAIN=base?
I don't really care either way; default on like you have is fine too as I don't fully understand the use case.

Check out rP154065.
All of the PRs linked there were filed in GNATS but were mapped over in BUGZILLA so they had the same numbers.
Had they been GNATS urls they would be more annoying to deal with IMO as the links would all be dead now. I realize this is an objective opinion. I would be comfortable with simply "https://bugs.freebsd.org/12344" as that can likely work forever.

Jilles mentioned on IRC a simpler way in the wrapper to enable it without the set -o call:

command set -o pipefail 2>/dev/null || :

In D16868#415222, @bdrewery wrote:

In D16868#415167, @bdrewery wrote:

In D16868#415150, @bdrewery wrote:

Has this turned up any bad pipelines in Makefiles?

Ah right there is that dd one from a while back.
Now that pipefail is in we could do this a lot simpler like tools/install.sh works.
I don't think it needs to be a MK_ option.
It doesn't need to install.
Maybe something like this could work in tools/sh.sh that we just set with __MAKE_SHELL=?

#! /bin/sh
set -o pipefail 2>/dev/null || :
exec "$@"

Hmm set -o pipefail || : doesn't actually ignore the error.

# sh -ec 'set -o pipefail || :; echo test'
set: Illegal option -o pipefail

:(

In D16868#415167, @bdrewery wrote:

In D16868#415150, @bdrewery wrote:

Has this turned up any bad pipelines in Makefiles?

Ah right there is that dd one from a while back.
Now that pipefail is in we could do this a lot simpler like tools/install.sh works.
I don't think it needs to be a MK_ option.
It doesn't need to install.
Maybe something like this could work in tools/sh.sh that we just set with __MAKE_SHELL=?

#! /bin/sh
set -o pipefail 2>/dev/null || :
exec "$@"

In D16868#415150, @bdrewery wrote:

Has this turned up any bad pipelines in Makefiles?

Has this turned up any bad pipelines in Makefiles?

This seems incomplete. It's just fixing the specific cases having problems today?
Why shouldn't we mandate enabling case-sensitivity on the filesystem first?

Looks ok. I didn't dive in very deep.

In D14244#388189, @emaste wrote:

I don't really like this, but given that any failure should be fairly straightforward to track down OK.
(I'd probably prefer some sort of #ifdef linux in getdtablecount.c itself with a #warning and a stub implementation.)

Thanks!

In D17899#382351, @bdrewery wrote:

I don't think this _must_ be in Makefile.inc1 but it's simpler to put it there to ensure the right bmake and share/mk is used, so fine to be there.

I don't think this _must_ be in Makefile.inc1 but it's simpler to put it there to ensure the right bmake and share/mk is used, so fine to be there.

reviewed and approved

In D16842#359095, @jhb wrote:

Agreed that as a followup we should define a single variable in src/Makefile.inc1 to hold 'freebsd12.0'. Will be useful since we are about to bump it to 13 in a few weeks.

I don't get emails for phabricator emails.
I do get and respond to IRC usually instantly.
Please get my feedback for further build changes.

Please also don't checkin generated files in the initial commit. As-is it makes it hard to review.

Can't evaluate lib/Makefile changes without the rest of the changes. I.e., does it require dependency changes in Makefile.inc1's make libraries handling? Can't tell from this.

Remove my blocker - I think it's fine in general if off-by-default