The make(1) variable DISTDIR is used by both ports and src with a
different meaning. Some users may set DISTDIR in /etc/make.conf
for ports, which previously worked fine when building src since
the src targets which used this variable were not very commonly
used (mainly, make distributeworld).
Unfortunately, with pkgbase becoming the default, this is no longer
true since make (update-)packages invokes make stageworld, which is
sensitive to DISTDIR, and these users find that their build now fails.
A correct fix for this probably requires renaming one or both of
the DISTDIR variables, but for now, work around the problem by
setting DISTDIR=/ for the user-facing pkgbase targets, packages
and update-package. Since setting DISTDIR doesn't work for these
targets anyway, this should not break any existing configurations.
MFC after: 1 week
PR: 290010
Reported by: Oleh Vinichenko <moonlapse81@gmail.com>
Reviewed by: imp, bapt
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D52929
The (update-)packages targets require buildworld and buildkernel to
run first. Add some .ORDER statements to ensure this happens.
This fixes 'make -j8 buildworld buildkernel packages'.
PR: 289969
Reported by: yasu
MFC after: 3 days
Reviewed by: yasu, emaste
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D52877
World and kernels for 32-bit powerpc can still be built using the
buildworld and buildkernel targets.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D51194
This broke `make makeman` by unconditionally adding output to all top
level targets. Lacking an obvious and trivial workaround, it makes
sense to back it out and rethink.
This reverts commit afa70490ee.
PR: 287274
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D51119
For some of our build targets such as buildworld, buildkernel etc. we log
the real time in seconds how long the build runs. Now we log the user and
system time as well in milliseconds for most build targets.
Example output:
make buildworld
[....]
>>> Time spent on target buildworld: real 2286.42 user 62870.84 sys 2294.22
PR: 287274
Firstly, if NEED_MAKE_UPGRADE isn't set, we shouldn't use whatever
bootstrapped bmake happens to be lying around. We're not going to re-run
the bmake target, so won't make sure it's up-to-date, and thus it could
be some ancient unsupported version. We can still, however, optimise
setting SUB_MAKE when the file exists, so long as it's guarded by
NEED_MAKE_UPGRADE.
Secondly, make kernel-toolchain should also bootstrap bmake if needed,
since it's supposed to be the subset of buildworld needed for building a
kernel.
Finally, if there is a stale bootstrapped bmake lying around that isn't
needed, delete it, since it will only cause confusion, and as far as I
can tell nothing else will clean it up, not even cleandir twice. So as
to ensure nobody's doing anything crazy with MYMAKE that would cause us
to delete something unexpected, or that would change behaviour by no
longer checking exists(${MYMAKE}) and using that regardless of version
checks, emit an error if the definition in use is not our own.
Reviewed by: emaste, sjg, imp
Differential Revision: https://reviews.freebsd.org/D48708
If USE_GCC_TOOLCHAINS is set to a value matching the pattern 'gcc*',
use that as the GCC version. For example, USE_GCC_TOOLCHAINS=gcc16
would use amd64-gcc16 for amd64, etc. If the variable is set to a
value that doesn't match that pattern, use the default version.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D48418
With it planned that armv7 will be the only 32-bit kernel when 15.0 is
released remove support for armv6.
Remove the top level build infrastructure. It was already removed from
universe, this just stops it from being built directly.
Reviewed by: mmel, emaste
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45634
This adds two new rules named create-packages-kernel-repo and
create-packages-world-repo.
The goal of those rules is to create the {kernel,world} packages and
after that the repository.
It helps a lot for developing with pkgbase by adding the dev machine
repository created by those rules on top of the official pkgbase one.
Differential Revision: https://reviews.freebsd.org/D43623
Reviewed by: bapt, emaste
Sponsored by: Beckhoff Automation GmbH & Co. KG
fmake has been out of the tree for 10 years / 5 major releases now. The
need to bootstrap from it has been gone for at least 6 if not 8
years. While we may still need to bootstrap bmake, we don't need to do
it from fmake, so only retail the infrastructure to update from bmake to
bmake. Retain, for now, the WANT_MAKE_VERSION stuff, though we're always
up to date when building from supported and quasi-supported platforms.
Also remove all the checks to see if .PARSEDIR is defined. It is always
defined and was an early, fail-safe way to tell fmake from bmake during
the transition.
Adjust comments that refer to old fmake and remove those no longer
relevant.
Sponsored by: Netflix
Reviewed by: brooks
Pull Request: https://github.com/freebsd/freebsd-src/pull/980
FreeBSD-src for all the sources but the kernel
FreeBSD-src-sys just for the kernel
MFC After: 3 days
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D42651
We currently pass MACHINE and MACHINE_ARCH as TARGET and TARGET_ARCH
respectively for universe-toolchain, but on non-FreeBSD these may not
have values that we understand (e.g. on Linux it will be x86_64 rather
than amd64) for TARGET/TARGET_ARCH (note that we do support them for
MACHINE/MACHINE_ARCH). Since the choice is a bit arbitrary and merely
determines what LLVM's default triple will be, use amd64 on non-FreeBSD
as a known-good default.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D41545
Per discussions over how to lighten the load of armv6, move it to an
extra arch. You can still build TARGET_ARCH=armv6 if you desire, but
it won't be built as part of 'make universe' without -DEXTRA_TARGETS.
Sponsored by: Netflix
These implement the steps that etcupdate (and mergemaster) need in order
to build their pristine trees, avoiding the need to use internal targets
and variables. Additionally, buildetc includes the steps needed to build
with BUILD_WITH_STRICT_TMPPATH enabled, since we need some host tools to
be available during the various build and install steps.
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D41205
This mirrors _cleanobj vs _obj, and will be used by etcupdate to ensure
its build tree has host tools available when BUILD_WITH_STRICT_TMPPATH
is enabled by default (whether in the source tree, like CheriBSD, or in
a system config file).
Note that due to line length the .MAKE .PHONY dependency line is split
into two, one for the filtered WMAKE_TGTS and one for the filtered
.ALLTARGETS.
Reviewed by: brooks, jhb
Differential Revision: https://reviews.freebsd.org/D41190
Rather than define the TARGETS and TARGET_ARCHES in src/Makefile
put them in sys.machine.mk so they can also be leveraged by
non-top-level builds.
We have TARGET_MACHINE_LIST as the list of MACHINES we build for.
For each MACHINE we have a MACHINE_ARCH_LIST_${MACHINE}
and the first entry of each list is used as default for
MACHINE_ARCH_${MACHINE}
We can now remove a bunch of MACHINE_ARCH.* handling from
local.sys.dirdeps*mk
Reviewed by: imp
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D40083
jobs.mk automates -j$JOB_MAX and capturing build log based on target.
Compute a default for JOB_MAX in local.sys.mk
Reviewed by: stevek, imp
Differential Revision: https://reviews.freebsd.org/D39683
Since 16fbf01912 PATH is no longer set
to a hardcoded value on non-FreeBSD build hosts, so we can end up with
spaces in $PATH. Instead of only escaping PATH I updated all `env PATH=`
uses in the toplevel makefile. While many of these currently can't
contain any special characters (since the build would have failed
already), in theory this gets us closer to allowing build/source
directory to contain e.g. spaces.
Allow the build process to find host binaries during the host-symlinks target when
cross-building on non-FreeBSD systems. Whilst most non-FreeBSD systems have all
the needed tools in /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin (the final
path added by host-symlinks itself), Homebrew for macOS on Arm defaults to
/opt/homebrew/bin, other more niche systems may also deviate and users may
expect tools in a customised PATH to be picked up, unlike on FreeBSD where we
want to ensure everything comes from base. In particular, (un)xz are needed
from Homebrew on macOS, and thus cannot be found on Arm without this.
Note that non-FreeBSD builds enforce BUILD_WITH_STRICT_TMPPATH, and so the
actual main build steps will still use a sanitised PATH.
Reviewed by: jrtc27, arichardson
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D37991
Similar to UPDATING and handbook changes, treat Makefile the same.
PR: 260822
Approved by: jhb, philip
Differential Revision: https://reviews.freebsd.org/D36877
With the meta-build, it's always a NO_CLEAN build. Provide a way to
remove so one can rebuild from scratch. 'cleankernel' will delete the
kernel and modules object directories. Document this in build(7).
Sponsored by: Netflix
Reviewed by: debdrup, markj
Differential Revision: https://reviews.freebsd.org/D32978
The text after .error et al is emitted verbatim.
Reviewed by: sjg
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33904
These targets generate a raw list of the candidate old files roughly
corresponding to the values of OLD_DIRS, OLD_FILES, and OLD_LIBS.
Currently list-old-files also includes uncompressed manpages in
addition to compressed manpages.
Use these targets in the implementation of check-old-* and
delete-old-* to replace duplicated logic.
Reviewed by: imp, emaste
Sponsored by: The University of Cambridge, Google Inc.
Differential Revision: https://reviews.freebsd.org/D33327
Summary: It's currently just as stable as powerpc64, with more ports working.
Reviewers: alfredo, bdragon, luporl, jhibbits, #manpages
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D33610
A number of header files in sys/* have, going back to 7th Edition Unix
in 1979, reqiured other files (like sys/types.h) to compile. Likewise
the 4BSD networking code has had prerequisites. However, going back to
around the turn of the 21st century, other systems have made them be
independently include-able (wide-spread header include protection
post-dates 7th edition Unix by maybe 3 or so years judging from USENET
source postings). Start down the path of making them all independently
include-able by creating this test that fails buildworld when they are
not.
The file 'badfiles.inc' contains a list of the currently broken files
that cannot be included w/o any prerequisites. As files are fixed, 'make
badfiles.inc' should be re-run to remove them from the list. Note: All
files that start with an underscore are considered internal and not
tested.
Please note: once a file is removed from badfiles.inc, it must pass on
all architectures. Buildworld through at least the _includes target is
needed to ensure its working (though a buildkernel should also be done
on all architectures as well).
Sponsored by: Netflix
Reviewed by: brooks, markj
Differential Revision: https://reviews.freebsd.org/D32498
Unlike the old fmake, running make FOO=bar when using bmake doesn't put
FOO=bar in .MAKEFLAGS at the top level, it instead just puts FOO in
.MAKEOVERRIDES and the full MAKEFLAGS will be formed for sub-makes.
Moreover, this only applies for sub-makes in rules, so this doesn't
apply to those in shell assignments. This means that the current check
does not catch make MAKEOBJDIRPREFIX=..., only those defined in config
files. Thus we must also check .MAKEOVERRIDES explicitly.
Reviewed by: sjg
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31015
In the CVS days this used be a wrapper around either CVS or CVSup and
used to support updating src, doc, and ports checkouts. With the move
to subversion this only supported updating src and was itself a
wrapper around 'svn update'. With Git, users are probably better off
using appropriate Git commands directly to update without needing an
explicit make target as a wrapper.
Reviewed by: bcr, imp, emaste
Differential Revision: https://reviews.freebsd.org/D30736
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
The new version only includes a specific version once, and uses the one
that's currently advised by tinderbox: -gcc6.
It also advises just installing the pkg, but mentions in a side-note at the
end where to find the source in the ports tree.
Reviewed by: jrtc27
Suggested by: jhb (use default from tinderbox)
Differential Revision: https://reviews.freebsd.org/D26820
This adds a new target update-packages which will create the new packages
compared to the last run.
This is how to use it:
At this point we cut a release
$ make buildworld ...
$ make buildkernel
$ make packages
There is now a PKG_VERSION directory with latest link pointing to it
Distribute the packages to server
$ something something that update the source tree
$ make buildworld ...
$ make buildkernel
$ make update-packages
You know have a PKG_VERSION directory in the REPODIR and latest link pointing to it.
In PKG_VERSION dir only the packages which differs from the latest run are
named PKG_VERSION, otherwise the old packages are there.
The process is :
Build the new packages in the PKG_VERSION directory
Compare the internal data with the PKG_VERSION_FROM version. The comparison is done
by checking the internal hash of the packages.
By default PKG_VERSION_FROM is set to what the latest link points to.
If the old and new version matches, we rm the new package and cp the old one.
Differential Revision: https://reviews.freebsd.org/D25984
LINT config files are about to be checked in directly. Eliminate
building them by hand here from NOTES files.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D26540
This is the initial set up for PowerPC64LE.
The current plan is for this arch to remain experimental for FreeBSD 13.
This started as a weekend learning project for me and kinda snowballed from
there.
(More to follow momentarily.)
Reviewed by: imp (earlier version), emaste
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D26399
${TARGET_ARCH} is empty here which results in empy MAKE_PARAMS being
passed to the buildkernel phase. This breaks the build when using the
strict TMPPATH since cc will not be included in $PATH.
Reviewed By: jhb
This uses GCC toolchains instead of LLVM on architectures supported by
GCC. Currently this uses GCC 6 on aarch64, amd64, i386, and mips.
Although this does also try to use GCC 6 on powerpc, it is always
skipped for now since a powerpc-gcc6 package is not available and the
structure of make universe makes it hard to skip a subset of arches
for a target. This should be short-lived as freebsd-gcc9 does include
a powerpc-gcc9 package so powerpc should work once this switches to
GCC 9.
Discussed with: emaste
Differential Revision: https://reviews.freebsd.org/D25732
