| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
and that controls which platforms are being built as part of a "make
universe". By default TARGETS is set to the 8 platforms currently
being built. This variable is useful for running or re-running a
"make universe" with only a selected set of platforms. This makes the
universe target slightly more useful in cases the universe is limited
to a developer's scope or objectives. For example, when a universe
failed for a particular platform and fixes need to be tested for that
particular platform then a developer can restart the universe for
only that platform, even if the initial universe is still building
other platforms.
|
| |
|
|
|
|
| |
DTrace.
|
|
|
|
|
| |
use with DTrace because the normal buildworld will do that when the
tools are built.
|
| |
|
|
|
|
|
|
| |
"make TARGET=<machine> build*", now that it actually works.
Prompted by: imp
|
|
|
|
|
|
|
|
|
|
|
| |
HISTORICAL_MAKE_WORLD from the text that's output. This was committed
against the previous consensus. Leave the documentation in this file
as a compromose. The HISTORICAL_MAKE_WORLD knob is intentionally
obfuscated and we only trust people smart enough to read the Makefile
to use it. All others have no business using it due to its danger,
unless DESTDIR is set.
Dissentors: grog, obrien, trhodes
|
| |
|
|
|
|
|
|
|
|
|
| |
undocumented HISTORICAL_MAKE_WORLD variable and set it. Note it
here so the blow up will not really be a surprise to people who
read.
Link the buildingworld chapter of our handbook in the README
while I'm here.
|
|
|
|
|
|
|
|
|
|
|
| |
environment for cross building (the same one you'd get interactively
in make buildenv). This cannot be a simple
make -f Makefile.inc1 -V WMAKEENV
because in PATH is not set correctly unless one takes a trip through
the Makefile/Makefile.inc1 indirection, the logic of which is too
large to reproduce outside of Makefiles.
|
|
|
|
|
|
|
|
| |
the build infrastructure: "make doxygen"
Changes to the man pages will be made when some defaults are revisited.
Requested by: gnn
|
| |
|
|
|
|
| |
Suggested by: phk
|
| |
|
|
|
|
|
|
|
| |
whether MAKEOBJDIRPREFIX is set at a wrong place.
Reviewed by: ru
MFC after: 3 days
|
|
|
|
| |
(the source for LINT), as I initially intended.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- removes obsolete files/dirs or libraries.
- works in interactive (default) and batch mode
- respects DISTDIR
- documented in UPDATING and build(7)
The head of the file ObsoleteFiles.inc contains instructions how to add
obsolete files/dirs/libs to the list. Obviously one should add obsolete
files to this list, when he removes a file/dir/lib from the basesystem.
Additionally add check-old target:
- allows re@ to check if a file on the obsolete list resurfaces
Design goals:
- allows full control by the user (default interactive mode)
- possibility of scripted removal of obsolete files (batch mode)
- opt-in removal of files (explicit list of files)
- seperate removal of libs (2 delete targets)
Important design decissions:
- structured list of files to remove instead of a plain text file:
* allows to remove additional files if a NO_foo knob is specified
without the need to change the targets (no NO_foo knob is respected
yet)
- not using mtree like NetBSD does:
* mtree doesn't has an interactive mode
Discussed on: arch (long ago), current (this year)
Additional input from: re (hrs)
Approved by: mentor (joerg)
|
|
|
|
|
|
|
| |
the "make -n universe" output looks more builder (human) friendly.
- Wrap the "universe" target into a ".if make(universe)"; it's only
intended to be called directly so it should be safe to do it.
|
|
|
|
|
| |
when cross-building (installing). (This is useful for NFS
installing world/kernel to another architecture machine.)
|
|
|
|
|
|
| |
Prodded by: obrien
Nodded by: peter
Approved by: re
|
|
|
|
|
|
|
|
| |
and adjust the path in the Makefile for the upgrade_checks target.
These checks are really feature upgrade checks that should be fast
and just find out whether we need to build a new make before
proceeding with other targets like buildworld. This makes the
place free for a real regression test suite in the old place.
|
|
|
|
|
|
| |
target of the same name from src/etc/Makefile with a proper
environment, suitable to be used during upgrades and cross-
builds.
|
|
|
|
|
|
|
| |
CAVEAT: if you run tcsh(1) from within this target, this will
reset your PATH making this target mostly useless. Careful!
Submitted by: jmg, ru
|
| |
|
|
|
|
| |
OK'ed by: core
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
testing for variables that are always defined (e.g.,
"make -V CC") would still print a false warning. Fix
this by only passing a submake the MAKEOBJDIRPREFIX=*
argument if it was present. As a result, we loose
the check for -DMAKEOBJDIRPREFIX, or an esoteric
"MAKEOBJDIRPREFIX = foo" (with embedded spaces), but
these are unorthodox enough to not care about them.
The make(1) bug mentioned in the previous revision
was just fixed in make/main.c,v 1.109.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When make flags are passed to make in the environment, the string is
chopped up in an (argc,argv) vector. This happens in brk_string() and
the chopped up string is stored in static buffer. When this includes
something like "-V BINMAKE", then a pointer into the static buffer is
put on the variables list for evaluation later. However, brk_string()
is used for more than just chopping up the MAKEFLAGS env. variable, so
it's very likely that the static buffer is clobbered. In fact, this is
exactly what happens.
The result is that _MAKEOBJDIRPREFIX gets assigned whatever garbage
the child make happens to emit, causing the test to fail. Like this:
pluto2% cd /usr/src
pluto2% make -V BINMAKE
"/q/6.x/src/Makefile", line 94: MAKEOBJDIRPREFIX can only be set in environment, not as a global (in /etc/make.conf) or command-line variable.
pluto2% make -dv -V BINMAKE | & grep _MAKEOBJDIRPREFIX
Global:_MAKEOBJDIRPREFIX = }
The fix is to not use MAKEFLAGS for this, but simple pass the flags
as arguments. Ideally make(1) should be fixed but that's beyond the
scope of my attention span.
This fixes release.
|
|
|
|
|
|
|
|
| |
by forcing the creation of an object directory for the make regression
tests. Let make handle the tracking of the dependency and installation
of test_shell script.
Submitted by: ru
|
|
|
|
|
|
|
|
|
|
|
|
| |
rates pretty high on the "hack!" scale, but it works for me. Adding
-DWANT_LIB32 to the world build command line, or 'WANT_LIB32=yes' to
/etc/make.conf will include the 32 bit libraries with the build.
I have not made this default behavior. Cross compiling this stuff is an
adventure I have not investigated.
This is still a WIP. We needed this at work so that we could install from
a readonly obj tree - lib32/build.sh wasn't up to that.
|
|
|
|
| |
binary is not in PATH, as is the case with installworld, etc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
built in parallel. Examples:
make universe
Build worlds sequentially, each world sequentially.
make universe JFLAG=-j4
Build worlds sequentially, each world in parallel.
make -j4 universe
make -j4 universe JFLAG=-j2
Build four worlds in parallel, each world will be
built in parallel too. World parallelization is
set to four in the first synopsis, and to two in
the second.
make -j4 universe JFLAG=-B
Build worlds in parallel, each world sequentially.
("world" == buildworld followed by buildkernels.)
Prayers: obrien, phk
|
|
|
|
|
| |
to suppress warnings with installworld and distributeworld when
env(1) cannot be found in the PATH.
|
|
|
|
|
|
|
|
|
| |
two -n flags. If only one -n flag is given the old behaviour
is retained (POLA). In order to make this working for installworld
change the IMAKEENV in this case so that the tools are found
(we have no temporary installation environment in this case).
Submitted by: ru (IMAKEENV part)
|
|
|
|
|
| |
rebuild things, further discouraging 'make world'. The title of
that section is now changed...
|
|
|
|
|
|
|
|
| |
more professional. While here, write a few lines of explanatory
text to explain what its for.
Discussed with: rwatson
With hat: core
|
| |
|
|
|
|
|
| |
enough this only seems to cause problems with -jX so went unnoticed
until now.
|
|
|
|
|
|
|
|
|
|
|
| |
trying to upgrade their system with make world instead of following
the preferred and suggested sequence of commands. The fact remains
that make world does not upgrade the kernel.
Allow make world when DESTDIR has been specified, including when
DESTDIR specifies the root file system. Otherwise, print a useful
warning and fail.
Reviewed, tested and scrutinized by: gad@
|
|
|
|
| |
make universe JFLAG=-j12
|
|
|
|
|
|
|
| |
a kernel. This is essentially the same as the toolchain target, except
that it does not build headers and libraries.
Submitted by: ru
|
|
|
|
|
|
|
| |
buildworld, up to and including libraries, except for actually
building the world.
Requested by: many
|
| |
|
|
|
|
| |
Approved by: peter
|
|
|
|
|
|
| |
targets like buildworld, installworld.
Suggested by: obrien
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
but the biggest issue is that there are situatons when
${.OBJDIR} == ${.SRCDIR}, and in those situations the previous version
would happily remove all your /usr/src while it was cleaning out the objects.
Not that *you* would be happy about it... Thanks to bde for immediately
noticing this serious possibility.
More improvements will be made to this target, but I wanted to commit this
safer version right now, before anyone lost their /usr/src due to it.
Reviewed by: bde
MFC after: 10 days
|
|
|
|
|
|
|
|
|
|
| |
that was built in previous 'make buildworld' and 'make buildkernel'. The
target knows enough to run a 'chflags -R 0' and a second 'rm' if the first
'rm' ran into any errors while removing files.
Suggested by: email with Richard Coleman Re: upcoming 64b-time_t changes.
Reviewed by: imp, marcel, and others on -hackers
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
Makefile.inc1 underscore targets with a big warning that they are
intentionally undocumented, subject to change without notice and
might poison your dog etc. If you don't know what they are, then they
are not meant for you to use.
I've added these by hand to so many many trees that I've lost count. I
find them rather useful.
|
|
|
|
|
|
| |
to become confused by a file called 'make' in /usr/src
Submitted by: ru
|
|
|
|
|
|
|
| |
do not have a chance to work nowadays as we have a lot of
internal libraries in lib/.
Discussed with: marcel, wollman
|