of submakes spawned during processing.
We create a fifo and stuff one character into it for each job we are
allowed to run. The name of the fifo is passed to child processes
in the MAKE_JOBS_FIFO environment variable.
A make which finds this variable on startup will open the fifo and
only spawn jobs when it managed to read a token from the fifo.
When the job completes a token is writen back to the fifo.
Slave make processes get one token for free: the one their parent
make got in order to run them. This makes the make processes
themselves invisible in the process counts.
The net effect is that "make -j 12 -s buildworld" will start at
most 12 jobs at the same time, instead of as previously up to
65 jobs would get started.
because the necessary files were not imported with the original import.
If somebody really needs it, there is still the devel/pmake port.
This is just the first step and removes just everything that is ifdef'ed out.
Otherwise the code is unchanged.
Checked by: md5
Approved by: no objections on arch@
the compat mode of operation and the != operator.
While here, fixed a bug in the .SHELL directive processing
when only the name= attribute is specified and no built-in
shell matches this name, causing null pointer dereference.
Obtained from: NetBSD (except for bugs)
the .MAKEFLAGS variable so that these are also passed to sub-makes.
This makes the handling of variables in the command environment more
consistent.
PR: bin/68853
Submitted by: Martin Kamerhofer <data@sbox.tugraz.at>
variable as required by POSIX. This causes such variables to be
pushed into all sub-makes called by the make (except when the MAKEFLAGS
variable is explicitely changed in the sub-make's environment).
This makes them also mostly un-overrideable in sub-makes except on the
sub-make's command line. Therefor specifying 'make CC=icc' will cause
icc to be used as C compiler in all sub-makes no matter what the Makefiles
itself try to do to the CC variable.
This patch also corrects the handling of the MFLAGS variable. MFLAGS
contains all the command line flags but not the command line variable
assignments. The evaluation of the .MFLAGS or .MAKEFLAGS target now
changes both MFLAGS and MAKEFLAGS (they used to change MAKEFLAGS only).
Makefiles can use MFLAGS for their own purposes given that they do not
except MFLAGS to be undefined at the beginning and that they don't evaluate
.MFLAGS or .MAKEFLAGS. MFLAGS should be removed for POSIX compliance,
but it is unfortunately heavily used by the X makefiles.
This has been extensively tested by port builds (thanks to portmgr), new
worlds and kernels.
PR: standards/57295 (1st part above)
Submitted by: James E. Flemer <jflemer@alum.rpi.edu>
Approved by: portmgr
Obtained from: NetBSD (1st part above)
MFC after: 4 weeks
terminates. Without this patch, 'make -j1 buildworld' takes about 30%
longer than 'make -B buildworld' on my 2.4 GHz P4; the difference is
probably even larger on faster systems. With this patch, there is no
perceptible difference in wall time between the two.
Submitted by: bde
MFC after: 3 days
into a separate function, Dir_InitDot().
- Postpone the current and object directories detection (and caching
of the "." directory) until after all command line arguments are
parsed. This makes the -C option DTRT.
PR: bin/47149
might help on the systems it could possibly be used as a bandaid for. In
fact, the only thing it's useful for is instrumenting free(3) calls, and in
that capacity, it's better served as a local patch, than a public wrapper.
compatability-geared util.c. These are things like message printers
and the PrintAddr function for traversing lists. Other general-purpose
utilities inside make(1) can go here, in time.
documentation already adequatedly existed in the description in most
cases. Where it did not, it was added. If no documentation existed
beforehand, then none was added. Some unused dummies for use in the
traversal functions were marked as __unused during the conversion.
Occasionally, local style fixes were applied to lines already being
modified or influenced.
Now make(1) should always build with WARNS=3.
there from being more than 500 processes forked by make(1), to prevent a
forkbomb from happening, in a dumb and mechanical way.
PR: alane
Submitted by: bin/42772
MFC after: 2 weeks
renaming variables to not shadow libc functions or greater scope locals. Kinda
makes one wonder if the extern ones weren't meant in some of these places :)
The only thing I'd still like to do WRT this is possibly combine rstat and
status in compat.c -- that should be fine, as I do not think the codepaths
will want both around at once.
Sponsored by: Bright Path Solutions
this particular GNU flag. It changes into the given directory for the
operation in question. This just goes into said directory at the time of
parsing the argument for getopt(3).
Submitted by: Rachel Hestilow <rachel@jerkcity.com>
we use in sublte ways with relative paths. Until they can be resolved,
back out these changes and put a big comment about why using realpath is
busted.
Approved by: jmallett
MFC After: 100 millifortnights
of ReadMakefile as __unused, it's there because this function is used by
the abstracted list interface which normally deals with item handlers which
take two arguments. Add a missing static prototype.
if a given make(1) is feature-compatible with a set of makefiles.
When merged, this will be used to replace the ugly upgrade_checks
hacks in src/Makefile.
Version has the RYYYYMMDDX format, where R is from RELENG_<R> and
X allows for 10 distinguishable changes per day.
Discussed with: bde
it, which means that relative paths will be expanded to absolute paths, and
filenames without a path will end up with their absolute path included as
well. This aids tremendously in debugging a build using our make(1) with
multiple Makefile's, such as when there is a syntax error in a file in a
sub-directory as per <bsd.subdir.mk>. Normally we'd end up with just
"Makefile" known about the Makefile in question, which means that an error
would be useless for someone trying to debug their build system, now we
end up with a complete real pathname for the Makefile.
So mostly this is useful in a debugging context, but possibly others too
(I haven't thought of them yet, but they probably are more useful if you
make Dir_FindFile use realpath(3), but that's another story).
Reviewed by: -current
MFC after: 2 weeks
test if failsafe memory allocation fails, it can't. perror -> warn. Use
failsafe memory allocation provided.
Use .Pa and .Ar. Uppercase (first letter) programname after dot.
