Retire MK_PROFILE infrastructure

It was disabled by default in fe52b7f60ef4. We planned to (but did not)
remove the option before FreeBSD 14. Remove it now, for FreeBSD 15.

Relnotes: Yes
Reviewed

Retire MK_PROFILE infrastructure

It was disabled by default in fe52b7f60ef4. We planned to (but did not)
remove the option before FreeBSD 14. Remove it now, for FreeBSD 15.

Relnotes: Yes
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31558

show more ...

Remove residual blank line at start of Makefile

This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix

Merge llvm-project main llvmorg-17-init-19304-gd0b54bb50e51

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-17-init-19304-gd0b54bb50e51, t

Merge llvm-project main llvmorg-17-init-19304-gd0b54bb50e51

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-17-init-19304-gd0b54bb50e51, the
last commit before the upstream release/17.x branch was created.

PR: 273753
MFC after: 1 month

show more ...

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Fix bootstrapping to actually build lldb-tblgen for later use

Because MK_LLDB=no is in BSARGS, the bootstrap-tools recursive make does
not add lldb-tblgen to _clang_tblgen, causing it to not be buil

Fix bootstrapping to actually build lldb-tblgen for later use

Because MK_LLDB=no is in BSARGS, the bootstrap-tools recursive make does
not add lldb-tblgen to _clang_tblgen, causing it to not be built. This
means that the build currently always uses the host's lldb-tblgen
(which, whilst currently it appears to work, could in future break if
TableGen backends are added or altered) and, if it doesn't exist (either
because the current FreeBSD system was built with it disabled, or you're
building on macOS/Linux), fails. Linux and macOS cross-builds used to
work simply because LLDB was previously in BROKEN_OPTIONS when building
on non-FreeBSD.

Instead, move MK_LLDB=no from BSARGS to XMAKE. This ensures that the
lib/clang build in cross-tools continues to not build LLDB parts for the
bootstrap toolchain (both to save time/space on FreeBSD, and because our
vendored LLDB does not include the macOS and Linux host files so those
would fail to build).

The DIRDEPS target is updated to move MK_LLDB=no from the BSARGS block
that mirrors Makefile.inc1 to the line that disables additional
toolchain components. The DIRDEPS build likely suffers from the same
issue currently, but having never used it and not being familiar with
how it works I am leaving that as-is. If it does suffer from the same
issue it should be easily reproducible by renaming /usr/bin/lldb-tblgen
or moving it to a directory not in PATH.

Fixes: 31ba4ce8898f ("Allow bootstrapping llvm-tblgen on macOS and Linux")
MFC after: 1 week
Reviewed by: dim, emaste, imp
Differential Revision: https://reviews.freebsd.org/D31531

show more ...

Prefer MK_SSP=no to SSP_CFLAGS=

It is more idiomatic. CFLAGS is only augmented with $SSP_CFLAGS when
$MK_SSP != "no".

Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freeb

Prefer MK_SSP=no to SSP_CFLAGS=

It is more idiomatic. CFLAGS is only augmented with $SSP_CFLAGS when
$MK_SSP != "no".

Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31401

show more ...

mk: format some option lists

Alphabetize and give each option its own line, ahead of making another
change to these lists. This makes future diffs easier to read.

Reviewed by: imp, emaste
MFC after

mk: format some option lists

Alphabetize and give each option its own line, ahead of making another
change to these lists. This makes future diffs easier to read.

Reviewed by: imp, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31399

show more ...

Rename NO_WERROR -> MK_WERROR=no

As suggested in D27598. This also supports MK_WERROR.clang=no and
MK_WERROR.gcc=no to support the existing NO_WERROR.<compiler> uses.

Reviewed By: brooks
Differenti

Rename NO_WERROR -> MK_WERROR=no

As suggested in D27598. This also supports MK_WERROR.clang=no and
MK_WERROR.gcc=no to support the existing NO_WERROR.<compiler> uses.

Reviewed By: brooks
Differential Revision: https://reviews.freebsd.org/D27601

show more ...

Stop passing MK_WARNS=no for bootstrap tools

I got annoyed by the number of warnings that the CheriBSD build was
emitting. It turns out that we are emitting lots of warnings during
bootstrap because

Stop passing MK_WARNS=no for bootstrap tools

I got annoyed by the number of warnings that the CheriBSD build was
emitting. It turns out that we are emitting lots of warnings during
bootstrap because bootstrap tools are built with the default compiler
flags and ignore the warnings flags that are set in bsd.sys.mk.

Looking at git blame, it appears that MK_WARNS=no has been passed since
rS112869, replacing the -DNO_WERROR option that was added in rS87775.

This commit changes MK_WARNS=no back to -DNO_WERROR. We need to pass
-DNO_WERROR, since the system compiler might have new warnings that we
don't know about yet, and we shouldn't fail the build in that case.

Reviewed By: imp, brooks
Differential Revision: https://reviews.freebsd.org/D27598

show more ...

Add WITH_CLANG_FORMAT option

clang-format is enabled conditional on either WITH_CLANG_EXTRAS or
WITH_CLANG_FORMAT. Some sources in libclang are build conditional on
either rule, and obviously the c

Add WITH_CLANG_FORMAT option

clang-format is enabled conditional on either WITH_CLANG_EXTRAS or
WITH_CLANG_FORMAT. Some sources in libclang are build conditional on
either rule, and obviously the clang-format binary itself depends on the
rule.

clang-format could still use a manual page.

Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D25427

show more ...

Merge ^/head r358400 through r358465.

remove GCC 4.2.1 build infrastructure

As described in Warner's email message[1] to the FreeBSD-arch mailing
list we have reached GCC 4.2.1's retirement date. At this time all
supported architecture

remove GCC 4.2.1 build infrastructure

As described in Warner's email message[1] to the FreeBSD-arch mailing
list we have reached GCC 4.2.1's retirement date. At this time all
supported architectures either use in-tree Clang, or rely on external
toolchain (i.e., a contemporary GCC version from ports).

GCC 4.2.1 was released July 18, 2007 and was imported into FreeBSD later
that year, in r171825. GCC has served us well, but version 4.2.1 is
obsolete and not used by default on any architecture in FreeBSD. It
does not support modern C and does not support arm64 or RISC-V.

Thanks to everyone responsible for maintaining, updating, and testing
GCC in the FreeBSD base system over the years.

So long, and thanks for all the fish.

[1] https://lists.freebsd.org/pipermail/freebsd-arch/2020-January/019823.html

PR: 228919
Reviewed by: brooks, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23124

show more ...

Merge ^/head r323559 through r325504.

MFhead@r325422

Fix nested MAKEOBJDIRPREFIX breaking various release/buildworld/toolchain targets.

This problem was caused by r325329 and r325350.

For the release(7) targets, some will run mm-mtree.sh which itself

Fix nested MAKEOBJDIRPREFIX breaking various release/buildworld/toolchain targets.

This problem was caused by r325329 and r325350.

For the release(7) targets, some will run mm-mtree.sh which itself runs make
with a MAKEOBJDIRPREFIX. The execution of that script leaks OBJROOT,
MAKEOBJDIR, and MAKELEVEL=1 in the environment. This causes the mm-mtree makes
to not do some basic setup of OBJROOT and only use this special
MAKEOBJDIRPREFIX case which fails to empty out MAKEOBJDIRPREFIX for further
nested makes, such as a tree walk. If that tree walk sets OBJROOT/OBJTOP such
as r325329 is doing, then the wrong OBJDIRs end up being used due to the
unemptied MAKEOBJDIRPREFIX being preferred over the proper MAKEOBJDIR.

Pointyhat to: bdrewery
Sponsored by: Dell EMC Isilon

show more ...

MFhead@r325383

Follow-up r325329: Store all WORLDTMP objects back in the same directory.

This still keeps the reduced MAKEOBJDIRPREFIX (SRCTOP) redundancy
removed in the OBJDIR, but now keeps all early phase objec

Follow-up r325329: Store all WORLDTMP objects back in the same directory.

This still keeps the reduced MAKEOBJDIRPREFIX (SRCTOP) redundancy
removed in the OBJDIR, but now keeps all early phase objects
in the same directory rather than split per phase.

The problem of splitting per phase is that later phases want to link in
libraries from earlier phases and base their location on ${OBJTOP}.

Pointyhat to: bdrewery
Reported by: mjoras, Mark Millard
Sponsored by: Dell EMC Isilon

show more ...

Reduce MAKEOBJDIRPREFIX path spam by specifying a direct objdir to use.

Sponsored by: Dell EMC Isilon

MFhead@r325199

Use more clear SRCTOP here.

Sponsored by: Dell EMC Isilon

Merge ^/head r319973 through 321382.

Merge ^/head r320042 through r320397.

buildworld: Pass which world phase the build is in down to submakes.

This is useful for having directories behave differently depending
on the phase - such as enabling SUBDIR_PARALLEL or disabling
r

buildworld: Pass which world phase the build is in down to submakes.

This is useful for having directories behave differently depending
on the phase - such as enabling SUBDIR_PARALLEL or disabling
redundant building of library directories already done by
earlier 'make _libraries'.

Sponsored by: Dell EMC Isilon

show more ...

MFhead @ r305314

Merge ^/head r305220 through r305300.