mirror of
https://git.savannah.gnu.org/git/make.git
synced 2024-10-23 20:59:55 +00:00
7ad2593b2d
Using anonymous pipes for jobserver support has some advantages: for example there is nothing on disk that needs to be cleaned up. However it has many obscure problems, related to the fact that in order for it to work we need to ensure these resources are properly passed through to child processes that want to use the jobserver. At the same time we don't want to pass the pipe to process which DON'T know about the jobserver. Other processes can open file descriptors which we then think are our jobserver, but aren't. And, we open the pipe file descriptors in blocking mode which doesn't work for all users. See issues such as SV 57178, SV 57242, and SV 62397 To avoid these issues, use named pipes (on systems where they are available) instead of anonoymous pipes. This simplifies many things: we never need to pass open file descriptors to our children; they can open the jobserver named pipe. We don't need to worry about recursive vs. non-recursive children. Users don't have to "pass through" the resources if they are invoking sub-makes. Each child can open its own file descriptor and set blocking as needed. The downside is the named pipe exists on disk and so must be cleaned up when the "top-level" make instance exits. In order to allow make to continue to be used in build systems where older versions of GNU make, or other tools that want to use the jobserver, but don't understand named pipes, introduce a new option --jobserver-style that allows the user to choose anonymous pipes. * NEWS: Announce the change and the --jobserver-style option. * doc/make.1: Add --jobserver-style documentation. * doc/make.texi (Special Variables): Add missing items to .FEATURES. (Options Summary): Add --jobserver-style. (POSIX Jobserver): Named pipes, changes to --jobserver-auth, and the --jobserver-style option. (Windows Jobserver): Document --jobserver-style for Windows. * configure.ac: Check for mkfifo. * src/config.h-vms.template: Undefined HAVE_MKFIFO. * src/config.h.W32.template: Ditto. * src/main.c: Add jobserver-style as a new command line option. (main): Add jobserver-fifo to .FEATURES if supported. Pass the style option to jobserver_setup(). * src/os.h (jobserver_setup): Accept a style string option. * src/posixos.c (enum js_type): Enumeration of the jobserver style. (js_type): Which style we are currently using. (fifo_name): The path to the named pipe (if in use). (jobserver_setup): If no style is given, or "fifo" is given, set up a named pipe: get a temporary file and use mkfifo() on it, then open it for reading and writing. If something fails fall back to anonymous pipes. (jobserver_parse_auth): Parse jobserver-auth to determine the style. If we are using a named pipe, open it. If we're using anonymous pipes ensure they're valid as before. (jobserver_get_invalid_auth): Don't invalidate the jobserver when using named pipes. (jobserver_clear): Clean up memory used for named pipes. (jobserver_acquire_all): Unlink the named pipe when done. * src/w32/w32os.c (jobserver_setup): Check the style argument. * tests/scripts/features/jobserver: Use --jobserver-style to test the anonymous pipe behavior, and also test named pipe/semaphore behavior. Check invalid jobserver-style options. * tests/scripts/functions/shell: Use --jobserver-style to test the anonymous pipe behavior, and also test named pipe/semaphore behavior. |
||
|---|---|---|
| .. | ||
| scripts | ||
| .gitignore | ||
| ChangeLog.1 | ||
| config-flags.pm.in | ||
| config-flags.pm.W32 | ||
| config_flags_pm.com | ||
| guile.supp | ||
| mkshadow | ||
| NEWS | ||
| README | ||
| run_make_tests | ||
| run_make_tests.bat | ||
| run_make_tests.com | ||
| run_make_tests.pl | ||
| test_driver.pl | ||
| thelp.pl | ||
The test suite was originally written by Steve McGee and Chris Arthur.
It is covered by the GNU General Public License (Version 2), described
in the file COPYING. It has been maintained as part of GNU make proper
since GNU make 3.78.
This entire test suite, including all test files, are copyright and
distributed under the following terms:
-----------------------------------------------------------------------------
Copyright (C) 1992-2022 Free Software Foundation, Inc.
This file is part of GNU Make.
GNU Make is free software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation; either version 3 of the License, or (at your option) any later
version.
GNU Make is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with
this program. If not, see <http://www.gnu.org/licenses/>.
-----------------------------------------------------------------------------
The test suite requires Perl. These days, you should have at least Perl
5.004 (available from ftp.gnu.org, and portable to many machines). It
used to work with Perl 4.036 but official support for Perl 4.x was
abandoned a long time ago, due to lack of testbeds, as well as interest.
The test suite assumes that the first "diff" it finds on your PATH is
GNU diff, but that only matters if a test fails.
To run the test suite on a UNIX system, use "perl ./run_make_tests"
(or just "./run_make_tests" if you have a perl on your PATH).
To run the test suite on Windows NT or DOS systems, use
"perl.exe ./run_make-tests.pl".
By default, the test engine picks up the first executable called "make"
that it finds in your path. You may use the -make_path option (i.e.,
"perl run_make_tests -make_path /usr/local/src/make-3.78/make") if
you want to run a particular copy. This now works correctly with
relative paths and when make is called something other than "make" (like
"gmake").
Tests cannot end with a "~" character, as the test suite will ignore any
that do (I was tired of having it run my Emacs backup files as tests :))
Also, sometimes the tests may behave strangely on networked
filesystems. You can use mkshadow to create a copy of the test suite in
/tmp or similar, and try again. If the error disappears, it's an issue
with your network or file server, not GNU make (I believe). This
shouldn't happen very often anymore: I've done a lot of work on the
tests to reduce the impacts of this situation.
The options/dash-l test will not really test anything if the copy of
make you are using can't obtain the system load. Some systems require
make to be setgid sys or kmem for this; if you don't want to install
make just to test it, make it setgid to kmem or whatever group /dev/kmem
is (i.e., "chgrp kmem make;chmod g+s make" as root). In any case, the
options/dash-l test should no longer *fail* because make can't read
/dev/kmem.
A directory named "work" will be created when the tests are run which
will contain any makefiles and "diff" files of tests that fail so that
you may look at them afterward to see the output of make and the
expected result.
There is a -help option which will give you more information about the
other possible options for the test suite.
Open Issues
-----------
The test suite has a number of problems which should be addressed. One
VERY serious one is that there is no real documentation. You just have
to see the existing tests. Use the newer tests: many of the tests
haven't been updated to use the latest/greatest test methods. See the
ChangeLog in the tests directory for pointers.
The second serious problem is that it's not parallelizable: it scribbles
all over its installation directory and so can only test one make at a
time. The third serious problem is that it's not relocatable: the only
way it works when you build out of the source tree is to create
symlinks, which doesn't work on every system and is bogus to boot. The
fourth serious problem is that it doesn't create its own sandbox when
running tests, so that if a test forgets to clean up after itself that
can impact future tests.
Bugs
----
Any complaints/suggestions/bugs/etc. for the test suite itself (as
opposed to problems in make that the suite finds) should be handled the
same way as normal GNU make bugs/problems (see the README for GNU make).
Paul D. Smith
Chris Arthur