The handling of "path" and "fullpath" was inconsistent, resulting in a
lot of missing dependencies regardless if a separate build directory
was in use.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
This target exists; use it, instead of effectively open-coding it into
the release script, causing bit rot and testing problems.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Don't break Makefile.dep generation if run from a separate build
directory.
config/unconfig.h is a bit special; it is kept in the repository for
the benefit of non-configure users. Therefore, don't have "make
spotless" delete it.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
config/unconfig.h really is no different than the other perlreq files,
so move it into the Makefile. This has the extra advantage that
config/unconfig.h no longer needs to be kept in the source repository.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Add warnings.src to PERLREQ. If this isn't done, warnings.src ends up
in the xdoc tarball rather than the release tarball, which means that
unless the user can "make warnings" manually (which requires Perl)
then they can't build the documentation.
As this only affects the documentation build, it probably does not
warrant a point release.
Add a few more extensions to the list of recognized binary extensions
for the purpose of generating a .zip file with DOS line ending
conventions.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
There is no reason to include both nasmdoc.pdf.xz and nasmdoc.pdf. For
the -xdoc file, the one with minimal dependencies is the proper one.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Clean up some perl warnings, some of which were legitimate (apparently
undef doesn't actually take a list of arguments, a common enough
mistake that it is mentioned in the man page!, and a list of variables
after "my" can be cantankerous), and some of which were nuisance but
were easy enough to clean up.
Maybe this can resolve the problems with very old version of Perl?
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
1. The mkdep.pl program didn't handle excluded dependencies correctly,
causing it to error out due to config/config.h not existing.
2. NMAKE is sensitive to the order suffixes appear in .SUFFIXES,
causing it to try to use the builtin rule .c.exe instead of
.c.obj -> .obj.exe.
3. NMAKE doesn't handle the && operator between commands.
4. The !ifdef jungle around dependency generation was wrong.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Make it possible to keep dependency information separate from the
Makefiles, so we don't have to deal with it noisifying the git logs.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
make really doesn't like something called MAKE in the environment, so
call it makej like buildall.sh on the server.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add indented paragraphs, which can be used to continue an item in a
bulleted list.
Produce valid strict XHTML, and include a style sheet with a navbar
and other fancy things.
Remove archaic output formats. Now only text, XHTML, and PDF are
supported.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Allow for multiple sections of Makefiles to be synchronized; the
intent is to use this to synchronize the Perl file generation rules.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The 2-operand form was inherently unsafe. Use the 3-operand form
instead, which guarantees that arbitrary filenames are supported.
This also means we can remove a few instances of sysopen() which was
used for exactly this reason, however, at least in theory sysopen()
isn't portable.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Sometimes we really want to use an extended pathname for an include
file, for documentation purposes; e.g. "config/config.h". This makes
alldeps handle that case correctly (and also adds the config/
directory to directories scanned by alldeps).
It is unclear if this will work correctly if there are include files
with the same name in different directories, but we currently do not
have any case like that.
Reported-by: anonymous coward <nasm64developer@users.sf.net>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Consistently identify dependencies by their path, not by their
basename. This avoids missing indirect dependencies. Furthermore, we
cannot start scanning files until we know the paths of all potential
targets.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Make the source code easier to understand and keep track of by
organizing it into subdirectories depending on the function.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
