Short: Port of GNU make with SAS/C (no ixemul.library required)
Author: GNU, Amiga port by Aaron "Optimizer" Digulla
Uploader: Aaron "Optimizer" Digulla (digulla@fh-konstanz.de)
Type: dev/c

This is a pure Amiga port of GNU make. It needs no extra libraries or
anything. It has the following features (in addition to any features of
GNU make):

- Runs Amiga-Commands with SystemTags() (Execute)
- Can run multi-line statements
- Allows to use Device-Names in targets:

        c:make : make.o

    is ok. To distinguish between device-names and target : or ::, MAKE
    looks for spaces. If there are any around :, it's taken as a target
    delimiter, if there are none, it's taken as the name of a device. Note
    that "make:make.o" tries to create "make.o" on the device "make:".
- Replaces @@ by a newline in any command line:

        if exists make @@\
            delete make.bak quiet @@\
            rename make make.bak @@\
        endif @@\
        $(CC) Link Make.o To make

    works. Note that the @@ must stand alone (i.e., "make@@\" is illegal).
    Also be careful that there is a space after the "\" (i.e., at the
    beginning of the next line).
- Can be made resident to save space and time
- Amiga specific wildcards can be used in $(wildcard ...)

BUGS:
- The line

    dummy.h : src/*.c

tries to make dummy.h from "src/*.c" (i.e., no wildcard-expansion takes
place). You have to use "$(wildcard src/*.c)" instead.

COMPILING FROM SCRATCH
----------------------

To recompile, you need SAS/C 6.51.

As of GNU make 4.3, the build environment has been cleaned up and alternate
make files (including smakefiles) have been removed.  If you have an existing
version of GNU make available you _should_ be able to run:

   make -f Basic.mk

However this is untested.

If you have an Amiga system and would like to collaborate on getting
bootstrapping to work properly please contact bug-make@gnu.org.

INSTALLATION

Copy make somewhere in your search path (e.g., sc:c or sc:bin).
If you plan to use recursive makes, install make resident:

    Resident make Add


-------------------------------------------------------------------------------
Copyright (C) 1995-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/>.

                                                            -*-indented-text-*-

GNU make can utilize the Customs library, distributed with Pmake, to
provide builds distributed across multiple hosts.

In order to utilize this capability, you must first download and build
the Customs library.  It is contained in the Pmake distribution, which
can be obtained at:

  ftp://ftp.icsi.berkeley.edu/pub/ai/stolcke/software/

This integration was tested (superficially) with Pmake 2.1.33.


BUILDING CUSTOMS
----------------

First, build pmake and Customs.  You need to build pmake first, because
Customs require pmake to build.  Unfortunately, this is not trivial;
please see the pmake and Customs documentation for details.  The best
place to look for instructions is in the pmake-2.1.33/INSTALL file.

Note that the 2.1.33 Pmake distribution comes with a set of patches to
GNU make, distributed in the pmake-2.1.33/etc/gnumake/ directory.  These
patches are based on GNU make 3.75 (there are patches for earlier
versions of GNU make, also).  The parts of this patchfile which relate
directly to Customs support have already been incorporated into this
version of GNU make, so you should _NOT_ apply the patch file.

However, there are a few non-Customs specific (as far as I could tell)
changes here which are not incorporated (for example, the modification
to try expanding -lfoo to libfoo.so).  If you rely on these changes
you'll need to re-apply them by hand.

Install the Customs library and header files according to the
documentation.  You should also install the man pages (contrary to
comments in the documentation, they weren't installed automatically for
me; I had to cd to the 'pmake-2.1.33/doc' directory and run 'pmake
install' there directly).


BUILDING GNU MAKE
-----------------

Once you've installed Customs, you can build GNU make to use it.  When
configuring GNU make, merely use the '--with-customs=DIR' option.
Provide the directory containing the 'lib' and 'include/customs'
subdirectories as DIR.  For example, if you installed the customs
library in /usr/local/lib and the headers in /usr/local/include/customs,
then you'd pass '--with-customs=/usr/local' as an option to configure.

Run make (or use build.sh) normally to build GNU make as described in
the INSTALL file.

See the documentation for Customs for information on starting and
configuring Customs.


INVOKING CUSTOMS-IZED GNU MAKE
-----------------------------

One thing you should be aware of is that the default build environment
for Customs requires root permissions.  Practically, this means that GNU
make must be installed setuid root to use Customs.

If you don't want to do this, you can build Customs such that root
permissions are not necessary.  Andreas Stolcke <stolcke@speech.sri.com>
writes:

 > pmake, gnumake or any other customs client program is not required to
 > be suid root if customs was compiled WITHOUT the USE_RESERVED_PORTS
 > option in customs/config.h.  Make sure the "customs" service in
 > /etc/services is defined accordingly (port 8231 instead of 1001).

 > Not using USE_RESERVED_PORTS means that a user with programming
 > skills could impersonate another user by writing a fake customs
 > client that pretends to be someone other than himself.  See the
 > discussion in etc/SECURITY.


PROBLEMS
--------

SunOS 4.1.x:
  The customs/sprite.h header file #includes the <malloc.h> header
  files; this conflicts with GNU make's configuration so you'll get a
  compile error if you use GCC (or any other ANSI-capable C compiler).

  I commented out the #include in sprite.h:107:

    #if defined(sun) || defined(ultrix) || defined(hpux) || defined(sgi)
    /* #include <malloc.h> */
    #else

  YMMV.


-------------------------------------------------------------------------------
Copyright (C) 1998-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/>.

Port of GNU Make to 32-bit protected mode on MSDOS and MS-Windows.

Builds with DJGPP v2 port of GNU C/C++ compiler and utilities.


New (since 3.74) DOS-specific features:

   1. Supports long filenames when run from DOS box on Windows 9x.

   2. Supports both stock DOS COMMAND.COM and Unix-style shells
      (details in 'Notes' below).

   3. Supports DOS drive letters in dependencies and pattern rules.

   4. Better support for DOS-style backslashes in pathnames (but see
      'Notes' below).

   5. The $(shell) built-in can run arbitrary complex commands,
      including pipes and redirection, even when COMMAND.COM is your
      shell.

   6. Can be built without floating-point code (see below).

   7. Supports signals in child programs and restores the original
      directory if the child was interrupted.

   8. Can be built without (a previous version of) Make.

   9. The build process requires only standard tools.  (Optional
      targets like "check:" still need additional programs, though,
      see below.)

  10. Beginning with v3.78, the test suite works in the DJGPP
      environment (requires Perl and auxiliary tools; see below).


To install a binary distribution:

   Simply unzip the makNNNb.zip file (where NNN is the version number)
   preserving the directory structure (-d switch if you use PKUNZIP).
   If you are installing Make on Windows 9X or Windows 2000, use an
   unzip program that supports long filenames in zip files.  After
   unzipping, make sure the directory with make.exe is on your PATH,
   and that's all you need to use Make.


To build from sources:

   1. Unzip the archive, preserving the directory structure (-d switch
      if you use PKUNZIP).  If you build Make on Windows 9X or Windows
      2000, use an unzip program that supports long filenames in zip
      files.

      If you are unpacking an official GNU source distribution, use
      either DJTAR (which is part of the DJGPP development
      environment), or the DJGPP port of GNU Tar.

   2. If you have a working Make already, you can run:

          make -f Basic.mk

   3. If you don't have a working Make already you can bootstrap one
      by running:

          .\builddos.bat

   4. If you are building from outside of the source directory, you
      need to tell Make where the sources are, like this:

          make -f c:/djgpp/gnu/make/Basic.mk SRCDIR=c:/djgpp/gnu/make

      or:

          c:/djgpp/gnu/make/builddos.bat c:/djgpp/gnu/make

   5. To run the test suite, type "make check".  This requires a Unix
      shell (I used the DJGPP port of Bash 2.03), Perl, Sed, Fileutils
      and Sh-utils.

   6. To install copy make.exe to the preferred location.

      Since GNU make 4.3, support for customized platform installations
      has been removed.  If you'd like to collaborate on reinstating
      these capabilities, contact bug-make@gnu.org.


Notes:
-----

   1. The shell issue.

      This is probably the most significant improvement, first
      introduced in the port of GNU Make 3.75.

      The original behavior of GNU Make is to invoke commands
      directly, as long as they don't include characters special to
      the shell or internal shell commands, because that is faster.
      When shell features like redirection or filename wildcards are
      involved, Make calls the shell.

      This port supports both DOS shells (the stock COMMAND.COM and its
      4DOS/NDOS replacements), and Unix-style shells (tested with the
      venerable Stewartson's 'ms_sh' 2.3 and the DJGPP port of 'bash' by
      Daisuke Aoyama <jack@st.rim.or.jp>).

      When the $SHELL variable points to a Unix-style shell, Make
      works just like you'd expect on Unix, calling the shell for any
      command that involves characters special to the shell or
      internal shell commands.  The only difference is that, since
      there is no standard way to pass command lines longer than the
      infamous DOS 126-character limit, this port of Make writes the
      command line to a temporary disk file and then invokes the shell
      on that file.

      If $SHELL points to a DOS-style shell, however, Make will not
      call it automatically, as it does with Unix shells.  Stock
      COMMAND.COM is too dumb and would unnecessarily limit the
      functionality of Make.  For example, you would not be able to
      use long command lines in commands that use redirection or
      pipes.  Therefore, when presented with a DOS shell, this port of
      Make will emulate most of the shell functionality, like
      redirection and pipes, and shall only call the shell when a
      batch file or a command internal to the shell is invoked.  (Even
      when a command is an internal shell command, Make will first
      search the $PATH for it, so that if a Makefile calls 'mkdir',
      you can install, say, a port of GNU 'mkdir' and have it called
      in that case.)

      The key to all this is the extended functionality of 'spawn' and
      'system' functions from the DJGPP library; this port just calls
      'system' where it would invoke the shell on Unix.  The most
      important aspect of these functions is that they use a special
      mechanism to pass long (up to 16KB) command lines to DJGPP
      programs.  In addition, 'system' emulates some internal
      commands, like 'cd' (so that you can now use forward slashes
      with it, and can also change the drive if the directory is on
      another drive).  Another aspect worth mentioning is that you can
      call Unix shell scripts directly, provided that the shell whose
      name is mentioned on the first line of the script is installed
      anywhere along the $PATH.  It is impossible to tell here
      everything about these functions; refer to the DJGPP library
      reference for more details.

      The $(shell) built-in is implemented in this port by calling
      'popen'.  Since 'popen' calls 'system', the above considerations
      are valid for $(shell) as well.  In particular, you can put
      arbitrary complex commands, including pipes and redirection,
      inside $(shell), which is in many cases a valid substitute for
      the Unix-style command substitution (`command`) feature.


   2. "SHELL=/bin/sh" -- or is it?

      Many Unix Makefiles include a line which sets the SHELL, for
      those versions of Make which don't have this as the default.
      Since many DOS systems don't have 'sh' installed (in fact, most
      of them don't even have a '/bin' directory), this port takes
      such directives with a grain of salt.  It will only honor such a
      directive if the basename of the shell name (like 'sh' in the
      above example) can indeed be found in the directory that is
      mentioned in the SHELL= line ('/bin' in the above example), or
      in the current working directory, or anywhere on the $PATH (in
      that order).  If the basename doesn't include a filename
      extension, Make will look for any known extension that indicates
      an executable file (.exe, .com, .bat, .btm, .sh, and even .sed
      and .pl).  If any such file is found, then $SHELL will be
      defined to the exact pathname of that file, and that shell will
      hence be used for the rest of processing.  But if the named
      shell is *not* found, the line which sets it will be effectively
      ignored, leaving the value of $SHELL as it was before.  Since a
      lot of decisions that this port makes depend on the gender of
      the shell, I feel it doesn't make any sense to tailor Make's
      behavior to a shell which is nowhere to be found.

      Note that the above special handling of "SHELL=" only happens
      for Makefiles; if you set $SHELL in the environment or on the
      Make command line, you are expected to give the complete
      pathname of the shell, including the filename extension.

      The default value of $SHELL is computed as on Unix (see the Make
      manual for details), except that if $SHELL is not defined in the
      environment, $COMSPEC is used.  Also, if an environment variable
      named $MAKESHELL is defined, it takes precedence over both
      $COMSPEC and $SHELL.  Note that, unlike Unix, $SHELL in the
      environment *is* used to set the shell (since on MSDOS, it's
      unlikely that the interactive shell will not be suitable for
      Makefile processing).

      The bottom line is that you can now write Makefiles where some
      of the targets require a real (i.e. Unix-like) shell, which will
      nevertheless work when such shell is not available (provided, of
      course, that the commands which should always work, don't
      require such a shell).  More important, you can convert Unix
      Makefiles to MSDOS and leave the line which sets the shell
      intact, so that people who do have Unixy shell could use it for
      targets which aren't converted to DOS (like 'install' and
      'uninstall', for example).


   3. Default directories.

      GNU Make knows about standard directories where it searches for
      library and include files mentioned in the Makefile.  Since
      MSDOS machines don't have standard places for these, this port
      will search ${DJDIR}/lib and ${DJDIR}/include respectively.
      $DJDIR is defined automatically by the DJGPP startup code as the
      root of the DJGPP installation tree (unless you've tampered with
      the DJGPP.ENV file).  This should provide reasonable default
      values, unless you moved parts of DJGPP to other directories.


   4. Letter-case in filenames.

      If you run Make on Windows 9x, you should be aware of the
      letter-case issue.  Make is internally case-sensitive, but all
      file operations are case-insensitive on Windows 9x, so
      e.g. files 'FAQ', 'faq' and 'Faq' all refer to the same file, as
      far as Windows is concerned.  The underlying DJGPP C library
      functions honor the letter-case of the filenames they get from
      the OS, except that by default, they down-case 8+3 DOS filenames
      which are stored in upper case in the directory and would break
      many Makefiles otherwise.  (The details of which filenames are
      converted to lower case are explained in the DJGPP libc docs,
      under the '_preserve_fncase' and '_lfn_gen_short_fname'
      functions, but as a thumb rule, any filename that is stored in
      upper case in the directory, is a valid DOS 8+3 filename and
      doesn't include characters invalid on MSDOS FAT filesystems,
      will be automatically down-cased.)  User reports that I have
      indicate that this default behavior is generally what you'd
      expect; however, your input is most welcome.

      In any case, if you hit a situation where you must force Make to
      get the 8+3 DOS filenames in upper case, set FNCASE=y in the
      environment or in the Makefile.


   5. DOS-style pathnames.

      There are a lot of places throughout the program sources which
      make implicit assumptions about the pathname syntax.  In
      particular, the directories are assumed to be separated by '/',
      and any pathname which doesn't begin with a '/' is assumed to be
      relative to the current directory.  This port attempts to
      support DOS-style pathnames which might include the drive letter
      and use backslashes instead of forward slashes.  However, this
      support is not complete; I feel that pursuing this support too
      far might break some more important features, particularly if
      you use a Unix-style shell (where a backslash is a quote
      character).  I only consider support of backslashes desirable
      because some Makefiles invoke non-DJGPP programs which don't
      understand forward slashes.  A notable example of such programs
      is the standard programs which come with MSDOS.  Otherwise, you
      are advised to stay away from backslashes whenever possible.  In
      particular, filename globbing won't work on pathnames with
      backslashes, because the GNU 'glob' library doesn't support them
      (backslash is special in filename wildcards, and I didn't want
      to break that).

      One feature which *does* work with backslashes is the filename-
      related built-in functions such as $(dir), $(notdir), etc.
      Drive letters in pathnames are also fully supported.



Bug reports:
-----------

   Bugs that are clearly related to the MSDOS/DJGPP port should be
   reported first on the comp.os.msdos.djgpp news group (if you cannot
   post to Usenet groups, write to the DJGPP mailing list,
   <djgpp@delorie.com>, which is an email gateway into the above news
   group).  For other bugs, please follow the procedure explained in
   the "Bugs" chapter of the Info docs.  If you don't have an Info
   reader, look up that chapter in the 'make.i1' file with any text
   browser/editor.


   Enjoy,
                        Eli Zaretskii <eliz@is.elta.co.il>


-------------------------------------------------------------------------------
Copyright (C) 1996-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/>.

                                                                     -*-text-*-

-------------------------------------------------------------------------------
Copyright (C) 2002-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 <https://www.gnu.org/licenses/>.
-------------------------------------------------------------------------------

Obtaining Git Code
------------------

This seems redundant, since if you're reading this you most likely have
already performed this step; however, for completeness, you can obtain the GNU
make source code via Git from the FSF's Savannah project
<https://savannah.gnu.org/projects/make/>:

  $ git clone git://git.savannah.gnu.org/make.git


Changes using Git
-----------------

If you do not have push privileges to the GNU make Git repository, see the
README file section "Submitting Patches" for information.

If you have push privileges to the GNU make Git repository keep this
information in mind:

Starting with GNU make 4.0 we no longer keep a separate ChangeLog file in
source control.  We use the Gnulib git-to-changelog conversion script to
convert the Git comments into ChangeLog-style entries for release.  As a
result, please format your Git comments carefully so they will look clean
after conversion.  In particular, each line of your comment will have a TAB
added before it so be sure your comment lines are not longer than 72
characters; prefer 70 or less.  Please use standard ChangeLog formats for
your commit messages (sans the leading TAB of course).

Rule #1: Don't rewrite pushed history (don't use "git push --force").

Typical simple workflow might be:

  * Edit files / make / make check
  * Use "git status" and "git diff" to verify your changes
  * Use "git add" to stage the changes you want to make
  * Use "git commit" to commit the staged changes to your local repository
  * Use "git pull" to accept & merge new changes from the Savannah repository
  * Use "git push" to push your commits back to the Savannah repository

For Emacs users, there are many options for Git integration but I strongly
recommend the Magit package: https://www.emacswiki.org/emacs/Magit
It makes the workflow much clearer, and has advanced features such as
constructing multiple commits from various files and even from different
diff chunks in the same file.  There is a video available which helps a lot.


Coding Standards
----------------

GNU make code adheres to the GNU Coding Standards.  Please use only spaces and
no TAB characters in source code.

Additionally, GNU make is a foundational bootstrap package for the GNU
project; as such it is conservative about language features it expects.
However, GNU make does rely on the Gnulib portability library, and Gnulib
currently requires a ISO C99 compiler.  So features in ISO C99 can be
assumed.


Building From Git for POSIX
---------------------------

To build GNU make from Git on POSIX systems such as GNU/Linux, you will
need to install the following extra software:

* autoconf
* automake >= 1.16.1
* gettext
* autopoint
* pkg-config
* texinfo (for makeinfo)
* GCC
* GNU make (POSIX make is not sufficient)

And any tools that those utilities require (GNU m4, etc.)

To run the tests you must install Perl.

To build a release you'll need to install lzip.

GNU make requires Gnulib to provide some facilities.  If you want to maintain
a local installation of gnulib you can set GNULIB_SRCDIR to point to it.
Otherwise, ./bootstrap will obtain a clone for you.

Unfortunately due to issues with gnulib's getloadavg, you must have automake
1.16.1 or above.  This version may not yet be available through GNU/Linux
package managers.  If you need to install from source be sure to set
ACLOCAL_PATH to point to the pkg-config location (e.g., /usr/share/aclocal).

If you want to build from Git with a non-GCC compiler, add "MAKE_CFLAGS=" to
your make command line (or at least remove any flags your compiler does not
support).

When building from Git you must build in the source directory: "VPATH
builds" from remote directories are not supported.  Once you've created
a distribution, of course, you can unpack it and do a VPATH build from
there.

After checking out the code, you will need to run the bootstrap script:

 $ ./bootstrap

At this point you have successfully brought your Git copy of the GNU
make source directory up to the point where it can be treated
more-or-less like the official package you would get from ftp.gnu.org.
That is, you can just run:

  $ ./configure
  $ make check

to build and test GNU make.

NOTE! This method builds GNU make in "maintainer mode".  Make programs built
      in this mode it will be slower, possibly MUCH slower: there are various
      sanity checks enabled.  Further this mode assumes a modern GCC, GNU
      libc, and well-formed system headers and enables a high level of
      warnings AND enables -Werror to turn warnings into failures.

      If you want to build from Git with "maintainer mode" disabled, add
      "MAKE_MAINTAINER_MODE=" to the make command line.  If you want to turn
      off the extra warning flags, add "MAKE_CFLAGS=" to the make command
      line.

      For example:
        $ ./configure
        $ make check MAKE_MAINTAINER_MODE= MAKE_CFLAGS=
        $ make install


Building From Git for Windows
-----------------------------

If you have a UNIX emulation like CYGWIN you can opt to run the general
build procedure above; it will work.  Consult README.W32.template for
information on options you might want to use when running ./configure.

If you can't or don't want to do that, then first run the .\bootstrap.bat
script to prime your Git workspace:

  > .\bootstrap.bat

Next, rename the file README.W32.template to README.W32 and follow those
instructions.


Debugging and Testing
---------------------

These instructions have been tested on GNU systems.  I have no idea if they
work on non-GNU systems (Windows, MacOS, etc.)

* Alternate Configurations:
  The maintMakefile has a rule for running configure with various different
  options, with and without packages.  Run:

    make check-alt-config

* Valgrind:
  You can run all tests under valgrind by passing the -memcheck option:

    (cd tests && ./run_make_tests -make ../make -memcheck)

  Note, this is slow!  Also some tests will fail because of invoking valgrind.

* ASAN:
  You can build with ASAN and run tests, like this:

    make clean
    make -j8 CFLAGS='-ggdb3 -fsanitize=address' LDFLAGS='-ggdb3 -fsanitize=address'
    (cd tests && ./run_make_tests -make ../make)

  Note that ASAN is reporting many more errors than valgrind.  I don't know
  which one is wrong: I haven't looked at them closely.


Creating a Package
------------------

Once you have performed the above steps (including the configuration and
build) you can create a GNU make package.  This is very simple, just
run:

  $ make dist-gzip

and, if you like:

  $ make dist-lzip

Even better, you should run this:

  $ make distcheck

Which will build both .gz and .lz package files, then unpack one into a
temporary location, try to build it and repack it, then verifying that
everything works, you get the same results, _and_ no extraneous files are
left over after the "distclean" rule.

This package can be unpacked and built to give a "normal" (non-maintainer
mode) result.


Steps to Release
----------------

Here are the things that need to be done (in more or less this order)
before making an official release.  If something breaks such that you need to
change code, be sure to start over again sufficiently that everything is
consistent (that's why we don't finalize the Git tag, etc. until the end).

  * Update the configure.ac file with the new release number.
  * Update the EDITION value in the doc/make.texi file.
  * Update the NEWS file with the release number and date.
  * Ensure the Savannah bug list URL in the NEWS file uses the correct
    "Fixed Release" ID number.
  * Run "make distcheck" to be sure it all works.
  * Run "make check-alt-config" to be sure alternative configurations work
  * Run "make update-makeweb" to get a copy of the GNU make web pages
  * Run "make update-gnuweb" to get a copy of the GNU website boilerplate pages
  * Update the web page boilerplate if necessary:
      ../gnu-www/www/server/standards/patch-from-parent ../make-web/make.html \
            ../gnu-www/www/server/standards/boilerplate.html
  * Run "make gendocs" (requires gnulib) to generate the manual files for
    the GNU make web pages.
  * Follow the directions from gendocs for the web page repository
  * run "make tag-release" to create a Git tag for the release
  * Push everything:
    git push --tags origin master

Manage the Savannah project for GNU make:

  >>> This is only for real releases, not release candidate builds <<<

  * In Savannah modify the "Value", "Rank", and "Description" values for the
    current "SCM" entry in both "Component Version" and "Fix Release" fields
    to refer to the new release.  The "Rank" field should be 10 less than the
    previous release so it orders properly.
  * In Savannah create a new entry for the "Component Version" and "Fix
    Release" fields:
      - Value: SCM
      - Rank:  20
      - Descr: Issues found in code retrieved from Source Code Management (Git), rather than a distributed version. Please include the SHA you are working with.

      - Descr: Fixed in Source Code Management (Git). The fix will be included in the next release of GNU make.

Start the next release:

  * Update configure.ac and add a ".90" to the release number.
  * Update the NEWS file with a new section for the release / date.
  * Update the Savannah URL for the bugs fixed in the NEWS section.


Publishing a Package
--------------------

In order to publish a package on the FSF FTP site, either the release
site ftp://ftp.gnu.org, or the prerelease site ftp://alpha.gnu.org, you
first need to have my GPG private key and my passphrase to unlock it.
And, you can't have them!  So there!  But, just so I remember here's
what to do:

  Make sure the "Steps to Release" are complete and committed and tagged.

  git clone git://git.savannah.gnu.org/make.git make-release

  cd make-release

  <run the commands above to build the release>

  make upload-alpha             # for alpha.gnu.org (pre-releases)
       -OR-
  make upload-ftp               # for ftp.gnu.org (official releases)

Depending on your distribution (whether GnuPG is integrated with your keyring
etc.) it will either pop up a window asking for your GPG key passphrase one
time, or else it will use the CLI to ask for the GPG passphrase _THREE_ times.
Sigh.


For both final releases and pre-releases, send an email with the URL of
the package to the GNU translation robot to allow the translators to
work on it:

     <coordinator@translationproject.org>


Where to Announce
-----------------

Create the announcement in a text file, using 'git shortlog',
then sign it with GPG:

  gpg --clearsign <announcement.txt>

Or, use your mail client's PGP/GPG signing capabilities.

Announce the release:

  * For release candidate builds:
    To:  bug-make@gnu.org
    CC:  coordinator@translationproject.org
    BCC: help-make@gnu.org, make-w32@gnu.org, make-alpha@gnu.org

  * For release builds
    To:  info-gnu@gnu.org, bug-make@gnu.org
    CC:  coordinator@translationproject.org
    BCC: help-make@gnu.org, make-w32@gnu.org, make-alpha@gnu.org

    * Add a news item to the Savannah project site.
    * Add an update to freecode.com (nee freshmeat.net)


Appendix A - For The Brave
--------------------------

For those of you who trust me implicitly, or are just brave (or
foolhardy), here is a canned sequence of commands to build a GNU make
distribution package from a virgin Git source checkout (assuming all the
prerequisites are available of course).

This list is eminently suitable for a quick swipe o' the mouse and a
swift click o' mouse-2 into an xterm.  Go for it!

For a debugging version:

./bootstrap && ./configure CFLAGS=-g && make check

For a release version

./bootstrap && ./configure && make check

Port of GNU make to OS/2.

Features of GNU make that do not work under OS/2:
  - remote job execution
  - dynamic load balancing


Special features of the OS/2 version:

Due to the fact that some people might want to use sh syntax in
Makefiles while others might want to use OS/2's native shell cmd.exe,
GNU make supports both shell types. The following list defines the order
that is used to determine the shell:

 1. The shell specified by the environment variable MAKESHELL.
 2. The shell specified by the SHELL variable within a Makefile. Like
    Unix, SHELL is NOT taken from the environment.
 3. The shell specified by the COMSPEC environment variable.
 4. The shell specified by the OS2_SHELL environment variable.
 5. If none of the above is defined /bin/sh is used as default.  This
    happens e.g. in the make testsuite.

Note: - Points 3 and 4 can be turned off at compile time by adding
        -DNO_CMD_DEFAULT to the CPPFLAGS.
      - DOS support is not tested for EMX and therefore might not work.
      - The UNIXROOT environment variable is supported to find /bin/sh
        if it is not on the current drive.


COMPILATION OF GNU MAKE FOR OS/2:

I. ***** SPECIAL OPTIONS *****

 - At compile time you can turn off that cmd is used as default shell
   (but only /bin/sh). Simply set CPPFLAGS="-DNO_CMD_DEFAULT" and make
   will not use cmd unless you cause it to do so by setting MAKESHELL to
   cmd or by specifying SHELL=cmd in your Makefile.

 - At compile time you can set CPPFLAGS="-DNO_CHDIR2" to turn off that
   GNU make prints drive letters. This is necessary if you want to run
   the testsuite.


II. ***** REQUIREMENTS FOR THE COMPILATION *****

A standard Unix like build environment:

 - sh compatible shell (ksh, bash, ash, but tested only with pdksh 5.2.14
   release 2)
   If you use pdksh it is recommended to update to 5.2.14 release 2. Older
   versions may not work! You can get this version at
   http://www.math.ohio-state.edu/~ilya/software/os2/pdksh-5.2.14-bin-2.zip
 - GNU file utilities (make sure that install.exe from the file utilities
   is in front of your PATH before X:\OS2\INSTALL\INSTALL.EXE. I recommend
   also to change the filename to ginstall.exe instead of install.exe
   to avoid confusion with X:\OS2\INSTALL\INSTALL.EXE)
 - GNU shell utilities
 - GNU text utilities
 - gawk
 - grep
 - sed
 - GNU make 3.79.1 (special OS/2 patched version) or higher
 - perl 5.005 or higher
 - GNU texinfo (you can use 3.1 (gnuinfo.zip), but I recommend 4.0)

If you want to recreate the configuration files (developers only!)
you need also: GNU m4 1.4, autoconf 2.59, automake 1.9.6 (or compatible)


III. ***** COMPILATION AND INSTALLATION *****

 a) ** Developers only - Everyone else should skip this section **
    To recreate the configuration files use:

      export EMXSHELL=ksh
      aclocal -I config
      automake
      autoconf
      autoheader


b) Installation into x:/usr

   Note: Although it is possible to compile make using "./configure",
         "make", "make install" this is not recommended.  In particular,
         you must ALWAYS use LDFLAGS="-Zstack 0x6000" because the default
         stack size is far to small and make will not work properly!

Recommended environment variables and installation options:

    export ac_executable_extensions=".exe"
    export CPPFLAGS="-D__ST_MT_ERRNO__"
    export CFLAGS="-O2 -Zomf -Zmt"
    export LDFLAGS="-Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio -Zstack 0x6000"
    export RANLIB="echo"
    ./configure --prefix=x:/usr --infodir=x:/usr/share/info --mandir=x:/usr/share/man --without-included-gettext
    make AR=emxomfar
    make install

Note: If you use gcc 2.9.x I recommend to set also LIBS="-lgcc"

Note: You can add -DNO_CMD_DEFAULT and -DNO_CHDIR2 to CPPFLAGS.
      See section I. for details.


IV. ***** NLS support *****

GNU make has NLS (National Language Support), with the following
caveats:

 a) It will only work with GNU gettext, and
 b) GNU gettext support is not included in the GNU make package.

Therefore, if you wish to enable the internationalization features of
GNU make you must install GNU gettext on your system before configuring
GNU make.

You can choose the languages to be installed. To install support for
English, German and French only enter:

  export LINGUAS="en de fr"

If you don't specify LINGUAS all languages are installed.

If you don't want NLS support (English only) use the option
--disable-nls for the configure script.  Note if GNU gettext is not
installed then NLS will not be enabled regardless of this flag.


V. ***** Running the make test suite *****

To run the included make test suite you have to set

  CPPFLAGS="-D__ST_MT_ERRNO__ -DNO_CMD_DEFAULT -DNO_CHDIR2"

before you compile make. This is due to some restrictions of the
testsuite itself. -DNO_CMD_DEFAULT causes make to use /bin/sh as default
shell in every case. Normally you could simply set MAKESHELL="/bin/sh"
to do this but the testsuite ignores the environment. -DNO_CHDIR2 causes
make not to use drive letters for directory names (i.e. _chdir2() and
_getcwd2() are NOT used).  The testsuite interprets the whole output of
make, especially statements like make[1]: Entering directory
'C:/somewhere/make-3.79.1/tests' where the testsuite does not expect the
drive letter. This would be interpreted as an error even if there is
none.

To run the testsuite do the following:

  export CPPFLAGS="-D__ST_MT_ERRNO__ -DNO_CMD_DEFAULT -DNO_CHDIR2"
  export CFLAGS="-Zomf -O2 -Zmt"
  export LDFLAGS="-Zcrtdll -s -Zlinker /exepack:2 -Zlinker /pm:vio -Zstack 0x6000"
  export RANLIB="echo"
  ./configure --prefix=x:/usr --disable-nls
  make AR=emxomfar
  make check

All tests should work fine with the exception of one of the "INCLUDE_DIRS"
tests which will fail if your /usr/include directory is on a drive different
from the make source tree.


-------------------------------------------------------------------------------
Copyright (C) 2003-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/>.

This directory contains the %VERSION% release of GNU Make.

See the file NEWS for the user-visible changes from previous releases.
In addition, there have been bugs fixed.

Please check the system-specific notes below for any caveats related to your
operating system.

If you are trying to build GNU make from a Git clone rather than a downloaded
source distribution, see the README.git file for instructions.

For source distribution building and installation instructions, see the file
INSTALL.

If you need to build GNU Make and have no other 'make' program to use, you can
use the shell script 'build.sh' instead.  To do this, first run 'configure' as
described in INSTALL.  Then, instead of typing 'make' to build the program,
type 'sh build.sh'.  This should compile the program in the current directory.
Then you will have a Make program that you can use for './make install', or
whatever else.

Some systems' Make programs cannot process the Makefile for GNU Make.  If you
get errors from your system's Make when building GNU Make, try using
'build.sh' instead.


GNU Make is free software.  See the file COPYING for copying conditions.
GNU Make is copyright by the Free Software Foundation.  Copyright notices
condense sequential years into a range; e.g. "1987-1994" means all years
from 1987 to 1994 inclusive.

Downloading
-----------

GNU Make can be obtained in many different ways.  See a description here:

  https://www.gnu.org/software/software.html


Documentation
-------------

GNU make is fully documented in the GNU Make manual, which is contained
in this distribution as the file make.texinfo.  You can also find
on-line and preformatted (PostScript and DVI) versions at the FSF's web
site.  There is information there about ordering hardcopy documentation.

  https://www.gnu.org/
  https://www.gnu.org/doc/doc.html
  https://www.gnu.org/manual/manual.html


Development
-----------

GNU Make development is hosted by Savannah, the FSF's online development
management tool.  Savannah is here:

  https://savannah.gnu.org

And the GNU Make development page is here:

  https://savannah.gnu.org/projects/make/

You can find most information concerning the development of GNU Make at
this site.


Bug Reporting
-------------

You can send GNU make bug reports to <bug-make@gnu.org>.  Please see the
section of the GNU make manual entitled 'Problems and Bugs' for
information on submitting useful and complete bug reports.

You can also use the online bug tracking system in the Savannah GNU Make
project to submit new problem reports or search for existing ones:

  https://savannah.gnu.org/bugs/?group=make

If you need help using GNU make, try these forums:

  help-make@gnu.org
  help-utils@gnu.org
  news:gnu.utils.help
  news:gnu.utils.bug


Submitting Patches
------------------

If you'd like to propose a change to GNU make, you can provide a patch with
your changes.  If you are making your changes in a Git workspace you can run
"git format-patch" to create a patch file.  If not, you can use the diff(1)
utility to create a patch file; please use "diff -u".

Once you have a patch you can submit it in any of these ways:

  * Create a bug on Savannah and add the patch as an attachment:
      https://savannah.gnu.org/bugs/?group=make&func=additem

  * Send the patch via email to <bug-make@gnu.org>: be sure to add it as an
    attachment to avoid interference by email processors.

Be aware that all non-trivial changes proposed for GNU make require FSF
copyright paperwork to be completed before they can be accepted.  Contact
<bug-make@gnu.org> for help.


Git Access
----------

The GNU make source repository is available via Git from the GNU Savannah Git
server; look here for details:

  https://savannah.gnu.org/git/?group=make

Please note: you won't be able to build GNU make from Git without installing
appropriate maintainer's tools, such as GNU m4, automake, autoconf, Perl, GNU
make, and GCC.

See the README.git file for instructions on how to build GNU make once these
tools are available.  We make no guarantees about the contents or quality of
the latest code in the Git repository: it is not unheard of for code that is
known to be broken to be checked in.  Use at your own risk.


System-specific Notes
---------------------

It has been reported that the XLC 1.2 compiler on AIX 3.2 is buggy such
that if you compile make with 'cc -O' on AIX 3.2, it will not work
correctly.  It is said that using 'cc' without '-O' does work.

The standard /bin/sh on SunOS 4.1.3_U1 and 4.1.4 is broken and cannot be
used to configure GNU make.  Please install a different shell such as
bash or pdksh in order to run "configure".  See this message for more
information:
  https://mail.gnu.org/archive/html/bug-autoconf/2003-10/msg00190.html

One area that is often a problem in configuration and porting is the code
to check the system's current load average.  To make it easier to test and
debug this code, you can do 'make check-loadavg' to see if it works
properly on your system.  (You must run 'configure' beforehand, but you
need not build Make itself to run this test.)

Another potential source of porting problems is the support for large
files (LFS) in configure for those operating systems that provide it.
Please report any bugs that you find in this area.  If you run into
difficulties, then as a workaround you should be able to disable LFS by
adding the '--disable-largefile' option to the 'configure' script.

On systems that support micro- and nano-second timestamp values and
where stat(2) provides this information, GNU make will use it when
comparing timestamps to get the most accurate possible result.  However,
note that many current implementations of tools that *set* timestamps do
not preserve micro- or nano-second granularity.  This means that "cp -p"
and other similar tools (tar, etc.) may not exactly duplicate timestamps
with micro- and nano-second granularity on some systems.  If your build
system contains rules that depend on proper behavior of tools like "cp
-p", you should consider using the .LOW_RESOLUTION_TIME pseudo-target to
force make to treat them properly.  See the manual for details.


Ports
-----

  - See README.customs for details on integrating GNU make with the
    Customs distributed build environment from the Pmake distribution.

  - See README.VMS for details about GNU Make on OpenVMS.

  - See README.Amiga for details about GNU Make on AmigaDOS.

  - See README.W32 for details about GNU Make on Windows NT, 95, or 98.

  - See README.DOS for compilation instructions on MS-DOS and MS-Windows
    using DJGPP tools.

    A precompiled binary of the MSDOS port of GNU Make is available as part
    of DJGPP; see the WWW page https://www.delorie.com/djgpp/ for more
    information.

    The Cygwin project maintains its own port of GNU make.  That port may have
    patches which are not present in this version.  If you are using Cygwin
    you should use their version of GNU make, and if you have questions about
    it you should start by asking on those mailing lists and forums.

Please note there are two _separate_ ports of GNU make for Microsoft
systems: a native Windows tool built with (for example) MSVC or Cygwin,
and a DOS-based tool built with DJGPP.  Please be sure you are looking
at the right README!


-------------------------------------------------------------------------------
Copyright (C) 1988-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 <https://www.gnu.org/licenses/>.

Overview:                                                       -*-text-mode-*-
---------

  This version of GNU make has been tested on:
  OpenVMS V8.3/V8.4 (Alpha) and V8.4 (Integrity) AND V7.3 (VAX)

  This version of GNU Make is intended to be run from DCL to run
  make scripts with a special syntax that is described below.  It
  likely will not be able to run unmodified Unix makefiles.

  There is an older implementation of GNU Make that was ported to GNV.
  Work is now in progress to merge that port to get a single version
  of GNU Make available.  When that merge is done, GNU Make will auto
  detect that it is running under a POSIX shell and then operate as close to
  GNU Make on Unix as possible.

  The descriptions below are for running GNU make from DCL or equivalent.

Recipe differences:
-------------------

  GNU Make for OpenVMS can not currently run native Unix make files because of
  differences in the implementation.

  I am trying to document the current behavior in this section.  This is based
  on the information in the file NEWS. and running the test suite.
  TODO: More tests are needed to validate and demonstrate the OpenVMS
  expected behavior.

  In some cases the older behavior of GNU Make when run from DCL is not
  compatible with standard makefile behavior.

  This behavior can be changed when running GNU Make from DCL by setting
  either DCL symbols or logical names of the format GNV$.  The settings
  are enabled with a string starting with one of '1', 'T', or 'E' for "1",
  "TRUE", or "ENABLE".  They are disabled with a '0', 'F', or 'D' for "1",
  "FALSE", or "DISABLE".  If they are not explicitly set to one of these
  values, then they will be set to their default values.

  The value of the setting DECC$FILENAME_UNIX_REPORT or
  DECC$FILENAME_UNIX_ONLY will now cause the $(dir x) function to return
  './' or '[]' as appropriate.

  The name GNV$MAKE_OLD_VMS when enabled will cause GNU Make to behave as
  much as the older method as can be done with out disabling VMS features.
  When it is disabled GNU Make have the new behavior which more closely
  matches Unix Make behavior.

  The default is currently the old behavior when running GNU Make from DCL.
  In the future this may change.  When running make from GNV Bash the new
  behavior is the default.

  This is a global setting that sets the default behavior for several other
  options that can be individually changed.  Many of the individual settings
  are to make it so that the self tests for GNU Make need less VMS specific
  modifications.

  The name GNV$MAKE_COMMA when enabled will cause GNU Make to expect a comma
  for a path separator and use a comma for the separator for a list of files.
  When disabled, it will cause GNU Make to use a colon for a path separator
  and a space for the separator for a list of files.  The default is to be
  enabled if the GNU Make is set to the older behavior.

  The name GNV$MAKE_SHELL_SIM when enabled will cause GNU Make to try to
  simulate a POSIX shell more closely.  The following behaviors occur:

    * Single quotes are converted to double quotes and any double
      quotes inside of them are doubled.  No environment variable expansion
      is simulated.
    * A exit command status will be converted to a POSIX Exit
      where 0 is success and non-zero is failure.
    * The $ character will cause environment variable expansion.
    * Environment variables can be set on the command line before a command.

  VMS generally uses logical name search lists instead of path variables
  where the resolution is handled by VMS independent of the program.  Which
  means that it is likely that nothing will notice if the default path
  specifier is changed in the future.

  Currently the built in VMS specific macros and recipes depend on the comma
  being used as a file list separator.
  TODO: Remove this dependency as other functions in GNU Make depend on a
  space being used as a separator.

  The format for recipes are a combination of Unix macros, a subset of
  simulated UNIX commands, some shell emulation, and OpenVMS commands.
  This makes the resulting makefiles unique to the OpenVMS port of GNU make.

  If you are creating a OpenVMS specific makefile from scratch, you should also
  look at MMK (Madgoat Make) available at https://github.com/endlesssoftware/mmk
  MMK uses full OpenVMS syntax and a persistent sub-process is used for the
  recipe lines, allowing multiple line rules.

  The default makefile search order is "makefile.vms", "gnumakefile",
  "makefile".  TODO: See if that lookup is case sensitive.

  When Make is invoked from DCL, it will create a foreign command
  using the name of executable image, with any facility prefix removed,
  for the duration of the make program, so it can be used internally
  to recursively run make().  The macro MAKE_COMMAND will be set to
  this foreign command.

  When make is launched from an exec*() command from a C program,
  the foreign command is not created.  The macro MAKE_COMMAND will be
  set to the actual command passed as argv[0] to the exec*() function.

  If the DCL symbol or logical name GNV$MAKE_USE_MCR exists, then
  the macro MAKE_COMMAND will be set to be an "MCR" command with the
  absolute path used by DCL to launch make.  The foreign command
  will not be created.

  The macro MAKE is set to be the same value as the macro MAKE_COMMAND
  on all platforms.

  Each recipe command is normally run as a separate spawned processes,
  except for the cases documented below where a temporary DCL command
  file may be used.

  BUG: Testing has shown that the commands in the temporary command files
  are not always created properly.  This issue is still under investigation.

  Any macros marked as exported are temporarily created as DCL symbols
  for child images to use.  DCL symbol substitution is not done with these
  commands.
  Untested: Symbol substitution.

  When a temporary DCL command file is used, DCL symbol substitution
  will work.

  For VMS 7.3-1 and earlier, command lines are limited to 255 characters
  or 1024 characters in a command file.
  For VMS 7.3-2 and later, command lines are limited to 4059 characters
  or 8192 characters in a command file.

  VMS limits each token of a command line to 256 characters, and limits
  a command line to 127 tokens.

  Command lines above the limit length are written to a command file
  in sys$scratch:.

  In order to handle Unix style extensions to VMS DCL, GNU Make has
  parsed the recipe commands and them modified them as needed.  The
  parser has been re-written to resolve numerous bugs in handling
  valid VMS syntax and potential buffer overruns.

  The new parser may need whitespace characters where DCL does not require
  it, and also may require that quotes are matched were DCL forgives if
  they are not.  There is a small chance that existing VMS specific makefiles
  will be affected.

  The '<', '>' was previously implemented using command files.  Now
  GNU Make will check to see if the is already a VMS "PIPE" command and
  if it is not, will convert the command to a VMS "PIPE" command.

  The '>>' redirection has been implemented by using a temporary command file.
  This will be described later.

  The DCL symbol or logical name GNV$MAKE_USE_CMD_FILE when set to a
  string starting with one of '1','T', or 'E' for "1", "TRUE", or "ENABLE",
  then temporary DCL command files are always used for running commands.

  Some recipe strings with embedded new lines will not be handled correctly
  when a command file is used.

  GNU Make generally does text comparisons for the targets and sources.  The
  make program itself can handle either Unix or OpenVMS format filenames, but
  normally does not do any conversions from one format to another.
  TODO: The OpenVMS format syntax handling is incomplete.
  TODO: ODS-5 EFS support is missing.
  BUG: The internal routines to convert filenames to and from OpenVMS format
  do not work correctly.

  Note: In the examples below, line continuations such as a backslash may have
  been added to make the examples easier to read in this format.
  BUG: That feature does not completely work at this time.

  Since the OpenVMS utilities generally expect OpenVMS format paths, you will
  usually have to use OpenVMS format paths for rules and targets.
  BUG: Relative OpenVMS paths may not work in targets, especially combined
  with vpaths.  This is because GNU make will just concatenate the directories
  as it does on Unix.

  The variables $^ and $@ separate files with commas instead of spaces.
  This is controlled by the name GNV$MAKE_COMMA as documented in the
  previous section.

  While this may seem the natural thing to do with OpenVMS, it actually
  causes problems when trying to use other make functions that expect the
  files to be separated by spaces.  If you run into this, you need the
  following workaround to convert the output.
  TODO: Look at have the $^ and $@ use spaces like on Unix and have
  and easy to use function to do the conversions and have the built
  in OpenVMS specific recipes and macros use it.

  Example:

comma := ,
empty :=
space := $(empty) $(empty)

foo: $(addsuffix .3,$(subs $(comma),$(space),$^)


  Makefile variables are looked up in the current environment. You can set
  symbols or logicals in DCL and evaluate them in the Makefile via
  $(<name-of-symbol-or-logical>).  Variables defined in the Makefile
  override OpenVMS symbols/logicals.

  OpenVMS logical and symbols names show up as "environment" using the
  origin function.  when the "-e" option is specified, the origin function
  shows them as "environment override".  On POSIX the test scripts indicate
  that they should show up just as "environment".

  When GNU make reads in a symbol or logical name into the environment, it
  converts any dollar signs found to double dollar signs for convenience in
  using DCL symbols and logical names in recipes.  When GNU make exports a
  DCL symbol for a child process, if the first dollar sign found is followed
  by second dollar sign, then all double dollar signs will be converted to
  single dollar signs.

  The variable $(ARCH) is predefined as IA64, ALPHA or VAX respectively.
  Makefiles for different OpenVMS systems can now be written by checking
  $(ARCH).  Since IA64 and ALPHA are similar, usually just a check for
  VAX or not VAX is sufficient.

  You may have to update makefiles that assume VAX if not ALPHA.

ifeq ($(ARCH),VAX)
  $(ECHO) "On the VAX"
else
  $(ECHO) "On the ALPHA  or IA64"
endif

  Empty commands are handled correctly and don't end in a new DCL process.

  The exit command needs to have OpenVMS exit codes.  To pass a POSIX code
  back to the make script, you need to encode it by multiplying it by 8
  and then adding %x1035a002 for a failure code and %x1035a001 for a
  success.  Make will interpret any POSIX code other than 0 as a failure.
  TODO: Add an option have simulate POSIX exit commands in recipes.

  Lexical functions can be used in pipes to simulate shell file test rules.

  Example:

  POSIX:
b : c ; [ -f $@ ] || echo >> $@

  OpenVMS:
b : c ; if f$$search("$@") then pipe open/append xx $@ ; write xx "" ; close xx


  You can also use pipes and turning messages off to silently test for a
  failure.

x = %x1035a00a

%.b : %.c
<tab>pipe set mess/nofac/noiden/nosev/notext ; type $^/output=$@ || exit $(x)


Runtime issues:

  The OpenVMS C Runtime has a convention for encoding a POSIX exit status into
  to OpenVMS exit codes.  These status codes will have the hex value of
  0x35a000.  OpenVMS exit code may also have a hex value of %x10000000 set on
  them.  This is a flag to tell DCL not to write out the exit code.

  To convert an OpenVMS encoded POSIX exit status code to the original code
  You subtract %x35a000 and any flags from the OpenVMS code and divide it by 8.

  WARNING: Backward-incompatibility!
  The make program exit now returns the same encoded POSIX exit code as on
  Unix. Previous versions returned the OpenVMS exit status code if that is what
  caused the recipe to fail.
  TODO: Provide a way for scripts calling make to obtain that OpenVMS status
  code.

  Make internally has two error codes, MAKE_FAILURE and MAKE_TROUBLE.  These
  will have the error "-E-" severity set on exit.

  MAKE_TROUBLE is returned only if the option "-q" or "--question" is used and
  has a POSIX value of 1 and an OpenVMS status of %x1035a00a.

  MAKE_FAILURE has a POSIX value of 2 and an OpenVMS status of %x1035a012.

  Output from GNU make may have single quotes around some values where on
  other platforms it does not.  Also output that would be in double quotes
  on some platforms may show up as single quotes on VMS.

  There may be extra blank lines in the output on VMS.
  https://savannah.gnu.org/bugs/?func=detailitem&item_id=41760

  There may be a "Waiting for unfinished jobs..." show up in the output.

  Error messages generated by Make or Unix utilities may slightly vary from
  POSIX platforms.  Typically the case may be different.

  When make deletes files, on POSIX platforms it writes out 'rm' and the list
  of files.  On VMS, only the files are written out, one per line.
  TODO: VMS

  There may be extra leading white space or additional or missing whitespace
  in the output of recipes.

  GNU Make uses sys$scratch: for the tempfiles that it creates.

  The OpenVMS CRTL library maps /tmp to sys$scratch if the TMP: logical name
  does not exist.  As the CRTL may use both sys$scratch: and /tmp internally,
  if you define the TMP logical name to be different than SYS$SCRATCH:,
  you may end up with only some temporary files in TMP: and some in SYS$SCRATCH:

  The default include directory for including other makefiles is
  SYS$SYSROOT:[SYSLIB] (I don't remember why I didn't just use
  SYS$LIBRARY: instead; maybe it wouldn't work that way).
  TODO:  A better default may be desired.

  If the device for a file in a recipe does not exist, on OpenVMS an error
  message of "stat: <file>: no such device or address" will be output.

  Make ignores success, informational, or warning errors (-S-, -I-, or
  -W-).  But it will stop on -E- and -F- errors. (unless you do something
  to override this in your makefile, or whatever).


Unix compatibility features:
----------------------------

  If the command 'echo' is seen, any single quotes on the line will be
  converted to double quotes.

  The variable $(CD) is implemented as a built in Change Directory
  command. This invokes the 'builtin_cd'  Executing a 'set default'
  recipe doesn't do the trick, since it only affects the sub-process
  spawned for that command.

  The 'builtin_cd' is generally expected to be on its own line.
  The 'builtin_cd' either from the expansion of $(CD) or directly
  put in a recipe line will be executed before any other commands in
  that recipe line.  DCL parameter substitution will not work for the
  'builtin_cd' command.

  Putting a 'builtin_cd' in a pipeline or an IF-THEN line should not be
  done because the 'builtin_cd' is always executed
  and executed first.  The directory change is persistent.

  Unix shell style I/O redirection is supported. You can now write lines like:
  "<tab>mcr sys$disk:[]program.exe < input.txt > output.txt &> error.txt"

  POSIX shells have ":" as a null command.  These are now handled.
  https://savannah.gnu.org/bugs/index.php?41761

  A note on appending the redirected output.  A simple mechanism is
  implemented to make ">>" work in action lines. In OpenVMS there is no simple
  feature like ">>" to have DCL command or program output redirected and
  appended to a file. GNU make for OpenVMS implements the redirection
  of ">>" by using a command procedure.

  The current algorithm creates the output file if it does not exist and
  then uses the DCL open/append to extend it.  SYS$OUTPUT is then directed
  to that file.

  The implementation supports only one redirected append output to a file
  and that redirection is done before any other commands in that line
  are executed, so it redirects all output for that command.

  The older implementation wrote the output to a temporary file in
  in sys$scratch: and then attempted to append the file to the existing file.
  The temporary file names looked like "CMDxxxxx.". Any time the created
  command procedure can not complete, this happens. Pressing CTRL+Y to
  abort make is one case.

  In case of CTRL+Y the associated command procedure is left in SYS$SCRATCH:.
  The command procedures will be named gnv$make_cmd*.com.

  The CtrlY handler now uses $delprc to delete all children. This way also
  actions with DCL commands will be stopped. As before the CtrlY handler
  then sends SIGQUIT to itself, which is handled in common code.

  Temporary command files are now deleted in the OpenVMS child termination
  handler. That deletes them even if a CTRL+C was pressed.
  TODO: Does the previous section about >> leaving files still apply?

  The behavior of pressing CTRL+C is not changed. It still has only an effect,
  after the current action is terminated. If that doesn't happen or takes too
  long, CTRL+Y should be used instead.


Build Options:

  Added support to have case sensitive targets and dependencies but to
  still use case blind file names. This is especially useful for Java
  makefiles on VMS:

<TAB>.SUFFIXES :
<TAB>.SUFFIXES : .class .java
<TAB>.java.class :
<TAB><TAB>javac "$<"
<TAB>HelloWorld.class :      HelloWorld.java

  A new macro WANT_CASE_SENSITIVE_TARGETS in config.h-vms was introduced.
  It needs to be enabled to get this feature; default is disabled.
  TODO: This should be a run-time setting based on if the process
  has been set to case sensitive.


Unimplemented functionality:

  The new feature "Loadable objects" is not yet supported. If you need it,
  please send a change request or submit a bug report.

  The new option --output-sync (-O) is accepted but has no effect: GNU make
  for OpenVMS does not support running multiple commands simultaneously.


Self test failures and todos:
-----------------------------

  The test harness can not handle testing some of the VMS specific modes
  because of the features needed for to be set for the Perl to run.
  Need to find a way to set the VMS features before running make as a
  child.

  GNU make was not currently translating the OpenVMS encoded POSIX values
  returned to it back to the POSIX values.  I have temporarily modified the
  Perl test script to compensate for it.  This should be being handled
  internally to Make.
  TODO: Verify and update the Perl test script.

  The features/parallelism test was failing. OpenVMS is executing the rules
  in sequence not in parallel as this feature was not implemented.
  GNU Make on VMS no longer claims it is implemented.
  TODO: Implement it.

  Symlink support is not present.  Symlinks are supported by OpenVMS 8.3 and
  later.

  Error messages should be suppressed with the "-" at the beginning of a line.
  On openVMS they were showing up.  TODO: Is this still an issue?

  The internal vmsify and unixify OpenVMS to/from UNIX are not handling logical
  names correctly.


Build instructions:
-------------------

  Don't use the HP C V7.2-001 compiler, which has an incompatible change
  how __STDC__ is defined. This results at least in compile time warnings.

Make a 1st version
       $ @makefile.com  ! ignore any compiler and/or linker warning
       $ copy make.exe 1st-make.exe

  Use the 1st version to generate a 2nd version as a test.
       $ mc sys$disk:[]1st-make clean  ! ignore any file not found messages
       $ mc sys$disk:[]1st-make

  Verify your 2nd version by building Make again.
       $ copy make.exe 2nd-make.exe
       $ mc sys$disk:[]2nd-make clean
       $ mc sys$disk:[]2nd-make


Running the tests:
------------------

  Running the tests on OpenVMS requires the following software to be installed
  as most of the tests are Unix oriented.

  * Perl 5.18 or later.
    https://sourceforge.net/projects/vmsperlkit/files/
  * GNV 2.1.3 + Updates including a minimum of:
    * Bash 4.3.30
    * ld_tools 3.0.2
    * coreutils 8.21
   https://sourceforge.net/p/gnv/wiki/InstallingGNVPackages/
   https://sourceforge.net/projects/gnv/files/

   As the test scripts need to create some foreign commands that persist
   after the test is run, it is recommend that either you use a sub-process or
   a dedicated login to run the tests.

   To get detailed information for running the tests:

   $ set default [.tests]
   $ @run_make_tests help

   Running the script with no parameters will run all the tests.

   After the the test script has been run once in a session, assuming
   that you built make in sys$disk:[make], you can redefined the
   "bin" logical name as follows:

   $ define bin sys$disk:[make],gnv$gnu:[bin]

   Then you can use Perl to run the scripts.

   $ perl run_make_tests.pl


Acknowledgments:
----------------

See NEWS. for details of past changes.

  These are the currently known contributors to this port.

  Hartmut Becker
  John Malmberg
  Michael Gehre
  John Eisenbraun
  Klaus Kaempf
  Mike Moretti
  John W. Eaton

This version of GNU make has been tested on:
  Microsoft Windows 2000/XP/2003/Vista/7/8/10
It has also been used on Windows 95/98/NT, and on OS/2.

It builds with the MinGW port of GCC (tested with GCC 3.4.2, 4.8.1,
and 4.9.3).

It also builds with MSVC 2.x, 4.x, 5.x, 6.x, 2005, 2008, 2010, 2012,
2013, and 2015 as well as with .NET 7.x and .NET 2003.

Building with Guile is supported (tested with Guile 2.0.x).  To build
with Guile, you will need, in addition to Guile itself, its dependency
libraries and the pkg-config program.  The latter is used to figure out
which compilation and link switches and libraries need to be mentioned
on the compiler command lines to correctly link with Guile.  A Windows
port of pkg-config can be found on ezwinports site:

  http://sourceforge.net/projects/ezwinports/

The libraries on which Guile depends can vary depending on your
version and build of Guile.  At the very least, the Boehm's GC library
will be needed, and typically also GNU MP, libffi, libunistring, and
libtool's libltdl.  Whoever built the port of Guile you have should
also provide you with these dependencies or a URL where to download
them.  A precompiled 32-bit Windows build of Guile is available from
the ezwinports site mentioned above.

The Windows port of GNU make is maintained jointly by various people.
It was originally made by Rob Tulloh.
It is currently maintained by Eli Zaretskii.


Do this first, regardless of the build method you choose:
---------------------------------------------------------

 1. Edit config.h.W32 to your liking (especially the few shell-related
    defines near the end, or HAVE_CASE_INSENSITIVE_FS which corresponds
    to './configure --enable-case-insensitive-file-system').  (We don't
    recommend to define HAVE_CASE_INSENSITIVE_FS, but you may wish to
    consider that if you have a lot of files whose names are in upper
    case, while Makefile rules are written for lower-case versions.)


Building with (MinGW-)GCC using build_w32.bat
---------------------------------------------

 2. Open a W32 command prompt for your installed (MinGW-)GCC, setup a
    correct PATH and other environment variables for it, then execute ...

        .\build_w32.bat gcc

    This produces gnumake.exe in the GccRel directory.

    If you want a version of GNU make built with debugging enabled,
    add the --debug option.  Output goes into the GccDebug directory.

    The batch file will probe for Guile installation, and will build
    gnumake.exe with Guile if it finds it.  If you have Guile
    installed, but want to build Make without Guile support, type

        .\build_w32.bat --without-guile gcc


Building with (MSVC++-)cl using build_w32.bat
---------------------------------------------

 2. Open a command shell, then execute ...

        .\build_w32.bat

    This produces a 64bit Release build of gnumake.exe in .\WinRel, using
    the compiler found on the %Path%.  If no compiler is found, the batch
    file will probe your system and choose the newest MSVC version it can
    find.

    If you want a 32bit version of GNU make, add the --x86 option.

    If you want a Debug build of GNU make, add the --debug option.  Output
    will go into the .\WinDebug directory.

    The batch file will probe for Guile installation, and will build
    gnumake.exe with Guile if it finds it.  If Guile is installed,
    but you prefer to build GNU make without Guile support, add the
    --without-guile option.


Building with (MinGW-)GCC using GNU make
----------------------------------------

 2. If you already have a version of GNU make available you can use it
    to build this version.  Open a W32 command prompt for your installed
    (MinGW-)GCC, setup a correct PATH and other environment variables
    for it, then execute ...

        make -f Basic.mk TOOLCHAIN=gcc

    This produces GccRel\gnumake.exe.
    If you want a version of GNU make built with debugging enabled,
    add the TARGET_TYPE=debug option:

        make -f Basic.mk TOOLCHAIN=gcc TARGET_TYPE=debug

    The makefile doesn't support Guile integration.  Use build_w32.bat
    if you want to build with Guile support.


Building with (MSVC++-)cl using GNU make
----------------------------------------

 2. If you already have a version of GNU make available you can use it
    to build this version.  Open a W32 command prompt for your installed
    (MSVC++-)cl, setup a correct PATH and other environment variables
    for it (usually via executing vcvars32.bat or vsvars32.bat from the
    cl-installation, or using a corresponding start menu entry from the
    cl-installation), then execute ...

        make -f Basic.mk

    This produces an optimized WinRel/gnumake.exe.
    If you want a version of GNU make built with debugging enabled,
    add the TARGET_TYPE=debug option:

        make -f Basic.mk TARGET_TYPE=debug

    The makefile doesn't support Guile integration.  Use build_w32.bat
    if you want to build with Guile support.


Running the test suite
----------------------

 3. You will need an installation of Perl.  Be sure to use a relatively
    modern version: older versions will sometimes throw spurious errors.

    To run the suite after building using GNU make, use:

        make -f Basic.mk check

    Alternatively if you'd like to run tests by hand, use:

        cd tests
        .\run_make_tests.bat -make <path-to-make>

    I've found <path-to-make> seems to want forward-slashes in the path.
    For example if building with .\build_w32.bat non-debug, use:

        cd tests
        .\run_make_tests.bat -make ../WinRel/gnumake.exe

    I've tested this with the MSYS2 shell and POSIX tools installation
    that you get by installing Git for Windows.



-------------------
-- Notes/Caveats --
-------------------

GNU make on Windows 32-bit platforms:

        This version of make is ported natively to Windows32 platforms
        (Windows NT 3.51, Windows NT 4.0, Windows 2000, Windows XP,
        Windows 95, and Windows 98). It does not rely on any 3rd party
        software or add-on packages for building. The only thing
        needed is a Windows compiler.  Two compilers supported
        officially are the MinGW port of GNU GCC, and the various
        versions of the Microsoft C compiler.

        Do not confuse this port of GNU make with other Windows32 projects
        which provide a GNU make binary. These are separate projects
        and are not connected to this port effort.

GNU make and sh.exe:

        This port prefers if you have a working sh.exe somewhere on
        your system. If you don't have sh.exe, the port falls back to
        MSDOS mode for launching programs (via a batch file).  The
        MSDOS mode style execution has not been tested that carefully
        though (The author uses GNU bash as sh.exe).

        There are very few true ports of Bourne shell for NT right now.
        There is a version of GNU bash available from Cygnus "Cygwin"
        porting effort (http://www.cygwin.com/).
        Other possibilities are the MKS version of sh.exe, or building
        your own with a package like NutCracker (DataFocus) or Portage
        (Consensys).  Also MinGW includes sh (http://mingw.org/).

GNU make and brain-dead shells (BATCH_MODE_ONLY_SHELL):

        Some versions of Bourne shell do not behave well when invoked
        as 'sh -c' from CreateProcess().  The main problem is they seem
        to have a hard time handling quoted strings correctly. This can
        be circumvented by writing commands to be executed to a batch
        file and then executing the command by calling 'sh file'.

        To work around this difficulty, this version of make supports
        a batch mode.  When BATCH_MODE_ONLY_SHELL is defined at compile
        time, make forces all command lines to be executed via script
        files instead of by command line.  In this mode you must have a
        working sh.exe in order to use parallel builds (-j).

        A native Windows32 system with no Bourne shell will also run
        in batch mode.  All command lines will be put into batch files
        and executed via $(COMSPEC) (%COMSPEC%).  However, parallel
        builds ARE supported with Windows shells (cmd.exe and
        command.com).  See the next section about some peculiarities
        of parallel builds on Windows.

Support for parallel builds

        Parallel builds (-jN) are supported in this port.  The number of
        concurrent processes has a hard limit of 4095.

GNU make and Cygnus GNU Windows32 tools:

        Good news! Make now has native support for Cygwin sh. To enable,
        define the HAVE_CYGWIN_SHELL in config.h and rebuild make
        from scratch. This version of make tested with B20.1 of Cygwin.
        Do not define BATCH_MODE_ONLY_SHELL if you use HAVE_CYGWIN_SHELL.

GNU make and the MKS shell:

        There is now semi-official support for the MKS shell. To turn this
        support on, define HAVE_MKS_SHELL in the config.h.W32 before you
        build make.  Do not define BATCH_MODE_ONLY_SHELL if you turn
        on HAVE_MKS_SHELL.

GNU make handling of drive letters in pathnames (PATH, vpath, VPATH):

        There is a caveat that should be noted with respect to handling
        single character pathnames on Windows systems.  When colon is
        used in PATH variables, make tries to be smart about knowing when
        you are using colon as a separator versus colon as a drive
        letter.  Unfortunately, something as simple as the string 'x:/'
        could be interpreted 2 ways: (x and /) or (x:/).

        Make chooses to interpret a letter plus colon (e.g. x:/) as a
        drive letter pathname.  If it is necessary to use single
        character directories in paths (VPATH, vpath, Path, PATH), the
        user must do one of two things:

         a. Use semicolon as the separator to disambiguate colon. For
            example use 'x;/' if you want to say 'x' and '/' are
            separate components.

         b. Qualify the directory name so that there is more than
            one character in the path(s) used. For example, none
            of these settings are ambiguous:

              ./x:./y
              /some/path/x:/some/path/y
              x:/some/path/x:x:/some/path/y

        Please note that you are free to mix colon and semi-colon in the
        specification of paths.  Make is able to figure out the intended
        result and convert the paths internally to the format needed
        when interacting with the operating system, providing the path
        is not within quotes, e.g. "x:/test/test.c".

        You are encouraged to use colon as the separator character.
        This should ease the pain of deciding how to handle various path
        problems which exist between platforms.  If colon is used on
        both Unix and Windows systems, then no ifdef'ing will be
        necessary in the makefile source.

Pathnames and white space:

        Unlike Unix, Windows 95/NT systems encourage pathnames which
        contain white space (e.g. C:\Program Files\). These sorts of
        pathnames are valid on Unix too, but are never encouraged.
        There is at least one place in make (VPATH/vpath handling) where
        paths containing white space will simply not work. There may be
        others too. I chose to not try and port make in such a way so
        that these sorts of paths could be handled. I offer these
        suggestions as workarounds:

                1. Use 8.3 notation. i.e. "x:/long~1/", which is actually
                   "x:\longpathtest".  Type "dir /x" to view these filenames
                   within the cmd.exe shell.
                2. Rename the directory so it does not contain white space.

        If you are unhappy with this choice, this is free software
        and you are free to take a crack at making this work. The code
        in w32/pathstuff.c and vpath.c would be the places to start.

Pathnames and Case insensitivity:

        Unlike Unix, Windows 95/NT systems are case insensitive but case
        preserving.  For example if you tell the file system to create a
        file named "Target", it will preserve the case.  Subsequent access to
        the file with other case permutations will succeed (i.e. opening a
        file named "target" or "TARGET" will open the file "Target").

        By default, GNU make retains its case sensitivity when comparing
        target names and existing files or directories.  It can be
        configured, however, into a case preserving and case insensitive
        mode by adding a define for HAVE_CASE_INSENSITIVE_FS to
        config.h.W32.

        For example, the following makefile will create a file named
        Target in the directory subdir which will subsequently be used
        to satisfy the dependency of SUBDIR/DepTarget on SubDir/TARGET.
        Without HAVE_CASE_INSENSITIVE_FS configured, the dependency link
        will not be made:

        subdir/Target:
                touch $@

        SUBDIR/DepTarget: SubDir/TARGET
                cp $^ $@

        Reliance on this behavior also eliminates the ability of GNU make
        to use case in comparison of matching rules.  For example, it is
        not possible to set up a C++ rule using %.C that is different
        than a C rule using %.c.  GNU make will consider these to be the
        same rule and will issue a warning.

SAMBA/NTFS/VFAT:

        I have not had any success building the debug version of this
        package using SAMBA as my file server. The reason seems to be
        related to the way VC++ 4.0 changes the case name of the pdb
        filename it is passed on the command line. It seems to change
        the name always to to lower case. I contend that the VC++
        compiler should not change the casename of files that are passed
        as arguments on the command line. I don't think this was a
        problem in MSVC 2.x, but I know it is a problem in MSVC 4.x.

        The package builds fine on VFAT and NTFS filesystems.

        Most all of the development I have done to date has been using
        NTFS and long file names. I have not done any considerable work
        under VFAT. VFAT users may wish to be aware that this port of
        make does respect case sensitivity.

FAT:

        Version 3.76 added support for FAT filesystems. Make works
        around some difficulties with stat'ing of files and caching of
        filenames and directories internally.

Bug reports:

        Please submit bugs via the normal bug reporting mechanism which
        is described in the GNU make manual and the base README.

-------------------------------------------------------------------------------
Copyright (C) 1996-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/>.

Indexes created Mon Jul 04 17:30:19 MDT 2022