During "make buildworld", building bmake is (one of) the very first steps
and we should not be building any of its tests. Conceptually, this is the
right thing to do 1) for build simplicity reasons and 2) because there is
no need to build any tests this early on.
In practice, this fixes tinderbox builds of CURRENT from 9.x when MK_TESTS
is enabled. This is because bsd.test.mk needs some modern bmake features
not present in 9.x (:tW) and tinderbox is forcing the build to use the
CURRENT share/mk files from the very beginning (see r266617). By skipping
the build of the tests when still using the host make, we omit the problem.
Arguably, what tinderbox is doing is wrong and needs to be addressed, but
that is a separate issue.
UPDATING. This is the first step towards the removal of ia64 from
head. A buildworld for ia64 will now yield:
% make buildworld
make[1]: "/usr/src/Makefile.inc1" line 151: Unknown target ia64:ia64.
While here, trim the ia64-specific additions from ObsoleteFiles.inc
Discussed at: BSDcan
in them. This is often the case, so just ignore the return
code. Actual errors that are found will also be detected downstream in
the rare cases where the return code is 2 instead of 1.
environments (that I can't reproduce locally, but that others have
reported) seem to get tripped up by this man page install. There's
really no need to do it, so turn off the man pages using the most
portable method. We can't just directly set MK_MAN=no here because
we're bootstrapping in the host environment and such a setting was
forbidden until very recently. NO_MAN= can produce a warning, but for
now the warning is benign.
build world, so it is the only make we build or install. fmake is
still in the tree, but disconnected, and upgrades from older systems
that still have bmake has not been removed, but its state has not been
tested (it should work given how minimal the work to upgrade to bmake
is).
#NO_UNIVERSE. Many of these config files are important examples, but
add little to no regresive value to the intended purpose of
UNIVERSE. We now build over 120 kernels during universe. There's
really little to no value to this over building say 60 or even 30 of
them (either is still a way too big number). This is especially true
for kernels that are nothing more than including a common base and
adding a static DTB file. Start by pruning 1/3 of the arm kernels that
add little regresion value.
commit 1d1b908107255ffdff4d17f015d8f057d73cc6cb
Author: Brooks Davis <brooks@one-eyed-alien.net>
Date: Fri Mar 28 16:24:45 2014 +0000
Add a long needed seatbelt.
Exit with an error when make is called without a target at the top level
rather than poluting the source tree and causing use confusion in future
builds.
commit a9d9aa341b2f4308a227ab460ba85f1f287ad028
Author: Brooks Davis <brooks@one-eyed-alien.net>
Date: Tue Apr 29 16:06:12 2014 +0000
Simplify seatbelt added in 1d1b908 based in feedback.
Discussed with: imp@FreeBSD.org
Reviewed by: imp
Sponsored by: DARPA, AFRL
This targets the existing ARMv6 and ARMv7 SoCs that contain a VFP unit.
This is an optional coprocessors may not be present in all devices, however
it appears to be in all current SoCs we support.
armv6hf targets the VFP variant of the ARM EABI and our copy of gcc is too
old to support this. Because of this there are a number of WITH/WITHOUT
options that are unsupported and must be left as the default value. The
options and their required value are:
* WITH_ARM_EABI
* WITHOUT_GCC
* WITHOUT_GNUCXX
In addition, without an external toolchain, the following need to be left
as their default:
* WITH_CLANG
* WITH_CLANG_IS_CC
As there is a different method of passing float and double values to
functions the ABI is incompatible with existing armv6 binaries. To use
this a full rebuild of world is required. Because no floating point values
are passed into the kernel an armv6 kernel with VFP enabled will work with
an armv6hf userland and vice versa.
broken. None of our kernels can boot armv6eb. The little-endian kernels do
not have the required code to be able to switch endian when running a
big-endian executable.
Approved by: re (gjb)
Include PROGNAME and DESTDIR in ${MMAKE} so that it doesn't need to be
passed to each make invocation.
Suggested by: hrs
Reviewed by: hrs
Approved by: re (gjb)
A HEAD buildworld on 9.x first bootstraps bmake, but this failed when
building with standalone debug. Pass in the PROGNAME override to the
'make all' stage as well as 'make install' so that the .debug file is
created with the correct name.
Reviewed by: sjg
Sponsored by: The FreeBSD Foundation
Approved by: re (rodrigc)
it gets built 16 times in parallel in the same location.
While we are at it, until we finish getting rid of fmake,
be explicit about the make we want to use, thus avoid the problem
of the temp make being the wrong version.
Reviewed by: obrien
so that job token pipe is passed to them.
To avoid surprising anyone, only add .MAKE to ${TGTS} when -n
has not been specified (at least for Makefile).
Reviewed by: obrien
make before starting the universe targets themselves. Otherwise, all of
the targets would attempt to build make simultaneously, overwriting each
other's copies of the make object files and executable. This could lead
to strange errors, for example when partially-written make executables
are invoked.
Also amend r216620, to make the rest of universe wait properly until the
upgrade_checks target is finished, by adding universe_${target}_prologue
to the .ORDER target. Otherwise, make will be too smart for its own
good, and start building the universe targets simultaneously with the
prologues anyway.
MFC after: 1 week
starting the kernels. Before this the kernels would be built as part of the
last architecture universe target. There can cause problems when this world
finishes before the other worlds as the host compiler may be picked up
rather than the target compiler.
The solution is to add a target to build the universe kernels that depends
on all the world targets finishing. As we may not be building a world only
depend on it when MAKE_JUST_KERNELS is undefined.
The automation can set TARGET_ARCH and TARGET and then make various
top-level targets, including buildLINT and buildkernel (with
KERNCONF=LINT). Previously there was no way to generate the LINT
kernel configuration without having to do something exceptionally
painful.
1. Don't do upgrade_checks when using bmake. As long as we have WITH_BMAKE,
there's a bootstrap complication in ths respect. Avoid it. Make the
necessary changes to have upgrade_checks work wth bmake anyway.
2. Remove the use of -E. It's not needed in our build because we use ?= for
the respective variables, which means that we'll take the environment
value (if any) anyway.
3. Properly declare phony targets as phony as bmake is a lot smarter (and
thus agressive) about build avoidance.
4. Make sure CLEANFILES is complete and use it on .NOPATH. bmake is a lot
smarter about build avoidance and should not find files we generate in
the source tree. We should not have files in the repository we want to
generate, but this is an easier way to cross this hurdle.
5. Have behavior under bmake the same as it is under make with respect to
halting when sub-commands fail. Add "set -e" to compound commands so
that bmake is informed when sub-commands fail.
6. Make sure crunchgen uses the same make as the rest of the build. This
is important when the make utility isn't called make (but bmake for
example).
7. While here, add support for using MAKEOBJDIR to set the object tree
location. It's the second alternative bmake looks for when determining
the actual object directory (= .OBJDIR).
Submitted by: Simon Gerraty <sjg@juniper.net>
Submitted by: John Van Horne <jvanhorne@juniper.net>
is something for make(1) to consume. Bmake gives output such as:
"warning: Couldn't read shell's output for "/bin/sh -c true"
Note we parted from traditional Pmake behavior in r18864 / r18255.
r238211:
Support TARGET_ARCH=armv6 and TARGET_ARCH=armv6eb
This adds a new TARGET_ARCH for building on ARM
processors that support the ARMv6K multiprocessor
extensions. In particular, these processors have
better support for TLS and mutex operations.
This mostly touches a lot of Makefiles to extend
existing patterns for inferring CPUARCH from ARCH.
It also configures:
* GCC to default to arm1176jz-s
* GCC to predefine __FreeBSD_ARCH_armv6__
* gas to default to ARM_ARCH_V6K
* uname -p to return 'armv6'
* make so that MACHINE_ARCH defaults to 'armv6'
It also changes a number of headers to use
the compiler __ARM_ARCH_XXX__ macros to configure
processor-specific support routines.
Submitted by: Tim Kientzle <kientzle@freebsd.org>
This makes our naming scheme more closely match other systems and the
expectations of much third-party software. MIPS builds which are little-endian
should require and exhibit no changes. Big-endian TARGET_ARCHes must be
changed:
From: To:
mipseb mips
mipsn32eb mipsn32
mips64eb mips64
An entry has been added to UPDATING and some foot-shooting protection (complete
with warnings which should become errors in the near future) to the top-level
base system Makefile.
second invocation only needs to operate on files with the immutable flag
set.
Submitted by: arundel (via private email) (original version)
Discussed on: -toolchain@
MFC after: 3 days
doc/, and now www/ trees, but only using the "cvsup" transport.
When "make update" is run using a tree's makefile, it can also use
"cvs" (except for www/) and "svn" (only src/).
Clean up documentation and code regarding "make update":
- Increase oddness by adding support for WWWSUPFILE and NO_WWWUPDATE to
Makefile.inc1 (analogous to PORTSSUPFILE/NO_PORTSUPDATE and
DOCSUPFILE/NO_DOCUPDATE; WWWSUPFILE already supported by www/Makefile).
- Document all trees that support CVS_UPDATE.
- Document all trees that support SUP_UPDATE.
- Document SVN_UPDATE.
- Document NO_WWWUPDATE.
- make.conf(5) mistakenly said that *SUPFILE* had defaults.
- Add an example entry for WWWSUPFILE.
Some files keep the SUN4V tags as a code reference, for the future,
if any rewamped sun4v support wants to be added again.
Reviewed by: marius
Tested by: sbruno
Approved by: re
this happens just before the build is started (within the same second)
CHECK_TIME actually triggers thinking param.h is in the future (see f_Xtime,
c_Xtime logi in find(1) sources for the details in !F_EXACTTIME case).
Using the -mtime -0s (seconds, rather than no unit) avoids this 1s race.
Submitted by: ed (2009-05-03)
Reviewed by: cperciva (2009-05-03), emaste
Tested by: bz (for almost two years)
MFC after: 4 days
infrastructure to use it. make distributeworld can now be used without
preparing its environment first and installs games into its distribution
using the regular make distribute logic instead of post-processing with
a script.
Also add two new targets, packageworld and packagekernel, that tar up the
results of distributeworld and distributekernel (also new), respectively.
then that target is invoked for each architecture rather than the
default action of building world and kernels for each architecture.
- Add a 'make toolchains' wrapper which uses UNIVERSE_TARGET to build
toolchains for all architectures.
- Document JFLAG, MAKE_JUST_KERNELS, and MAKE_JUST_WORLDS variables for
'make universe'.
Reviewed by: bz
MFC after: 1 week
need to do this because variables specified on the command line
override those specified in the Makefile. This is why we also moved
from TARGET to _TARGET in Makefile, and then set TARGET on the command
line when we fork a submake with Makefile.inc1.
This makes mips/mips work again, even without the workaround committed to
lib/libc/Makefile.
Properly document what `make targets` is supposed to list to avoid
further confusion given the place the target sits. Should have happened
with r217125.
Requested by: imp [1]
Reviewed by: rwatson
combinations) by forcing FAILFILE into .CURDIR as we do for all other
universe output files. [1] Similarly make FAILFILE start with "_." as well.
Reviewed by: silence-on-src [1]
MFC after: 6 days
This produces a list of currently supported targets. Here "supported"
means "built in make universe" on the theory that those targets are
more supported than any that might work in 'make buildworld TARGET=x
TARGET_ARCH=y' since the latter are less tested.
Suggested by: rwatson
Implement MACHINE_ARCH=mips64e[lb] to build N64 images. This replaces
MACHINE_ARCH=mipse[lb] TARGET_ABI=n64.
MACHINE_ARCH=mipsn32e[lb] has been added, but currently requires
WITHOUT_CDDL due to atomic issues in libzfs. I've not investigated
this much, but implemented this to preserve as much of the TARGET_ABI
functionality that I could. Since its presence doesn't affect the
working cases, I've kept it in for now.
Added mips64e[lb] to make universe, so more kernels build.
And I think this (finally) closes the curtain on the tbemd tree.
not the one we build as part of make world. This means that make
universe will fail if building on a too-old current or any stable
system prior to a few days ago in weird ways (parse errors from
shell). This copes with these old systems in two ways:
(1) Works around the WARNING: issue by filtering all warnings that
sneak onto stdout.
(2) if TARGET_ARCH_${kernel} winds up being empty, then we error out
immediately with a semi-useful error message. This usually comes from
config not groking -m.
Ideally, we'd use a buildworld's config here, but that's tricky, so
I'll leave that detail to others to fix (it has to be done post make
world for the arch rather than at the top level makefile). This
should make 'make universe' usable from recent 8-stable systems
(recent == last few months or so) for building -current. They have
-m, but spewed warnings out stdout. Older systems will now at least
get a firm error early rather than a confusing error late.
and powerpc64 to universe for the first time. In general, provide
(slightly hacky) knowledge of multi-architecture TARGETs to universe as
well as the ability to distinguish the correct toolchain for a given
kernel using config -m.
semantics for JFLAG with tinderbox as for universe. Previously doing
'make JFLAG=-j4 tinderbox' was equivalent to 'make -j4 universe'
(i.e. 4 worlds in parallel) rather than 'make JFLAG=-j4 universe'
(i.e. worlds in sequence, each built with -j4).
MFC after: 1 month
TARGET_BIG_ENDIAN is now completely dead, except where it was
originally supposed to be used (internally in the toolchain building).
TARGET_ARCH has changed in three cases:
(1) Little endian mips has changed to mipsel.
(2) Big endian mips has changed to mipseb.
(3) Big endian arm has changed to armeb.
Some additional changes are needed to make 'make universe' work on arm
and mips after this change, so those are commented out for now.
UPDATING information will be forthcoming. Any remaining rough edges
will be hammered out in -current.
Remove __gnu89_inline.
Now that we use C99 almost everywhere, just use C99-style in the pmap
code. Since the pmap code is the only consumer of __gnu89_inline, remove
it from cdefs.h as well. Because the flag was only introduced 17 months
ago, I don't expect any problems.
Reviewed by: alc
It was backed out, because it prevented us from building kernels using a
7.x compiler. Now that most people use 8.x, there is nothing that holds
us back. Even if people run 7.x, they should be able to build a kernel
if they run `make kernel-toolchain' or `make buildworld' first.
make universe, split the logic into two parts:
- 1st to build worlds and generate kernel configs like LINT.
- 2nd to build kernels for a given TARGET architecture correctly
finding all newly generated configs, not knowing anything about
LINT anymore. (*)
(*) If you know better/cleaner/... ways to do this, let me know.
Discussed on/with: arch, jhb, rwatson
MFC after: 1 month
you can build the cross development tools and install them as
$XDEV-freebsd-xxx for each tool. This allows one to use autoconf to
find the tools for cross building scenarios.
`make universe'. This catches a few more arm and, once enabled, mips
configs and permits having local configs named like NOINET6.
Reviewed by: phk
MFC after: 4 weeks
a developer can rest reasonably assured that the tinderbox will not
be broken. This target leverages most of 'universe' but will exit
non-zero and output a summary at the end.
"make tinderbox"
no active development on it for over a year now and it isn't
reliable under a simple buildworld. Developers can't be expected to
test code targeted for it.
