Options should be in sort(1) order by primary option (usually, but not
always, first in the if statement).
Reviewed by: emaste, imp, netchild
Pull Request: https://github.com/freebsd/freebsd-src/pull/896
(cherry picked from commit 4cd0f014a1285c1b57e583b260282ca433a8ccdd)
These used to be grouped with MK_GCOV option or the like.
Reviewed by: emaste, imp, netchild
Pull Request: https://github.com/freebsd/freebsd-src/pull/896
(cherry picked from commit fb173fc89e9c6908426bf60b1a449f1ff19d51df)
Presumably these were under MK_CDDL at some point, but these days
src.opts.mk takes care of setting them to "no" when MK_CDDL is.
Reviewed by: emaste, imp, netchild
Pull Request: https://github.com/freebsd/freebsd-src/pull/896
(cherry picked from commit a62cefbb5c835eb17057bca98106f325b13bdead)
Using sort(1) order makes verification of the sort easier.
Reviewed by: emaste, imp, netchild
Pull Request: https://github.com/freebsd/freebsd-src/pull/896
(cherry picked from commit 4ca5df80393e1f2bf6ac26af42fc7246acb59f71)
This is currently a no-op but can matter for downstreams whose ${make}
includes additional settings.
Reviewed by: imp, emaste
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D41777
(cherry picked from commit 9c80d66ec1b4c5b9ac7aaf5b0fdbb1628d49c181)
Fixes: 74da9c39c346 ("pkgbase: Split out manpages by default")
Sponsored by: The FreeBSD Foundation
(cherry picked from commit d3a9d605a8963b7833936fd9679b734871facab4)
The "allnodes" code is currently #if 0 so also #if 0 the setting of the
command line option and variable in order to keep wlanstats compiling.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 530c13c5401c1f29f8325cf851d96778852a1ba3)
ProPolice refers to a specific implementation by Hiroaki Etoh and
Kunikazu Yoda. The implementation in contemporary Clang and GCC is
somewhat different and newer, so use a generic term in the src.conf
descriptions.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit b461276d75488fe50c1503db85d43cbb8c3c3067)
Two more profile libraries that should be removed by WITHOUT_PROFILE.
Found when upgrading a stable/13 VM to stable/14.
Approved by: re (gjb)
(cherry picked from commit 023ef8015ee6c4e76b63db310800a0f2512fea72)
The top-level Makefile passes -m to its sub-makes in order to ensure
they use the in-tree mk files in share/mk, but the top-level make itself
has to rely on whatever environment the bmake used has. For FreeBSD, we
configure the system bmake with .../share/mk:/usr/share/mk, which means
it will pick up src's share/mk whenever run from within the src tree,
but currently for non-FreeBSD we configure our bootstrap bmake only with
bmake's own mk files. This is mostly compatible, with two exceptions:
1. "targets" runs at the top level, but needs TARGET_MACHINE_LIST and
the corresponding MACHINE_ARCH_LIST_${target}, otherwise it will just
print an empty list.
2. "universe" and "universe-toolchain", when run at the top level (i.e.
not via the various wrappers around universe like tinderbox), end up
failing in universe-toolchain itself with:
bmake[1]: "/path/to/freebsd/share/mk/src.sys.obj.mk" line 112: Cannot use MAKEOBJDIR=
Unset MAKEOBJDIR to get default: MAKEOBJDIR='${.CURDIR:S,^${SRCTOP},${OBJTOP},}'
By including .../share/mk in the default sys path like FreeBSD's system
bmake we ensure that we get the in-tree mk files for the top-level make,
not just sub-makes, and avoid such issues.
Note that we cannot (yet) stop using the installed mk files, since the
MAKEOBJDIRPREFIX check in Makefile runs in the object directory and uses
env -i, thereby losing the MAKESYSPATH exported by src.sys.env.mk. Other
such issues may also exist, though are likely rare if so.
Reviewed by: sjg
Differential Revision: https://reviews.freebsd.org/D41544
We currently assume that any existing bootstrapped bmake binary will
work, but this means it never gets updated as contrib/bmake is, and
similarly we won't rebuild it as and when the configure arguments given
to boot-strap change. Whilst the former isn't necessarily a huge problem
given WANT_MAKE_VERSION rarely gets bumped in Makefile, having fewer
variables is a good thing, and so it's easiest if we just always keep it
up-to-date rather than trying to do something similar to what's already
in Makefile (which may or may not be accurate, given updating FreeBSD
gives you an updated bmake, but nothing does so for our bootstrapped
bmake on non-FreeBSD). The latter is more problematic, though, and the
next commit will be changing this configuration.
We thus now add in two checks. The first is to compare MAKE_VERSION
against _MAKE_VERSION from contrib/bmake/VERSION. The second is to
record at bootstrap time the exact configuration used, and compare that
against what we would bootstrap with.
Reviewed by: arichardson, sjg
Differential Revision: https://reviews.freebsd.org/D41556
Systems that predate 971bac5ace ("kbd: consolidate kb interfaces
(phase one)") cannot build kbdcontrol since kbdelays and kbrates moved
to sys/kbio.h. Moreover, on non-FreeBSD, it requires all kinds of ioctls
and sysctls that are highly FreeBSD-specific to build, but we use it as
a bootstrap tool to generate the keymaps used by some kernels (LINT ones
in particular). Thus, when bootstrapping kbdcontrol, disable everything
that's not needed for that singular use, and use the in-tree kbio.h to
get the definitions of the necessary structures.
This allows KBDMUX_DFLT_KEYMAP, UKBD_DFLT_KEYMAP and ATKBD_DFLT_KEYMAP
to be enabled when building on non-FreeBSD, and thus LINT kernels.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D41541
- Prune headers and tests no longer installed after the upgrade.
- Remove GoogleTest-related files when MK_GOOGLETEST == no.
- Disable `-Werror` with gcc to unbreak the gcc12 CI run with
`lib/googletest`. Any issues found by g++ will be filed
upstream and hopefully resolved in a future version.
- Remove clang -Werror issues which are resolved in version 1.14.0 to
avoid masking valid issues.
MFC after: 1 week
MFC with: 28f6c2f292
This change updates `make delete-old` to account for files installed by the
following options:
- MK_BSDINSTALL
- MK_DMAGENT
- MK_EXAMPLES
- MK_SENDMAIL
MFC after: 2 weeks
9600 was a standard baud rate decades ago, but 115200 is now more common
so choose defaults that are useful to the largest number of users.
Note that boot0sio does not support rates above 9600 so it remains
unchanged.
Reviewed by: bz, imp, manu
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36295
Use at your own risk, but this will remove $FreeBSD$ from your tree. It
does commits and tries to be at least a little smart about it.
Sponsored by: Netflix
At the moment, several Makefiles under tests/ do not correctly generate
.depend files, which can lead to link errors when doing incremental
(e.g. WITHOUT_CLEAN) builds:
ld: error: undefined symbol: testing::internal::g_linked_ptr_mutex
>>> referenced by gtest-port.h:2137 (/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private/gtest/internal/gtest-port.h:2137)
>>> mockfs.o:(testing::internal::linked_ptr_internal::depart())
>>> referenced by gtest-port.h:2139 (/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private/gtest/internal/gtest-port.h:2139)
>>> mockfs.o:(testing::internal::linked_ptr_internal::depart())
>>> referenced by gtest-port.h:2139 (/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private/gtest/internal/gtest-port.h:2139)
>>> mockfs.o:(testing::internal::linked_ptr_internal::depart())
>>> referenced 3 more times
For the time being, put in a depend-cleanup.sh workaround for this.
Reported by: des
Reviewed by: emaste
Fixes: 28f6c2f292
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D41476
Toolchain components were historically statically linked. They became
normal dynamically linked executables in commit 6ab18ea64d. There is
no need to keep a special case build option for the toolchain; users who
want statically linked toolchain (or any other) components can use the
existing NO_SHARED knob.
Reviewed by: dim, sjg
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41266
Prior to Clang 13 (e.g. in the Clang 11 present in 13.0-RELEASE), the
resource directory logic for FreeBSD was broken and would not resolve
symlinks, meaning symlinks would only work if in a directory next to the
containing lib directory. Therefore we cannot even use a symlink for
worldtmp, we have to make a wrapper script that execs the real binary
via an absolute path.
Reported by: markj
Reviewed by: markj
Fixes: 65f28f63a7 ("tools/build: Create toolchain symlinks for non-absolute compiler/linker")
Differential Revision: https://reviews.freebsd.org/D41238
