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.
only matters in the early stages of bootstrapping, of course, but gnu make can't
handle bsd make Makefiles at all if they use any of the 'dot' directives, which
src/Makefile has in abudnance.
