Significantly improve the portability/reliability of a general
make command. Build a .pdf.xz version of the documentation,
using an uncompressed pdf as basis.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
It turns out that we need a Fontmap file after all, *and* -I. to make
gs find it. Inconsistent results came from stray Fontmap files from
previous debug attempts.
Now generate both fontpath and Fontmap, and hopefully at least one of
them should work. We might, in fact, need both, one for gs to know
where the files are and one for gs to know it is allowed to read them.
The core problem seems to be that gs will find OTF fonts by its normal
discovery mechanisms, but for some reason don't seem to use them
unless it can find them in a Fontmap, Font directory, of CIDFont
directory.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
It is extremely desirable to allow the user fine-grained control of
warnings, but this has been complicated by the fact that a warning
class has had to be defined in no less than three places (error.h,
error.c, nasmdoc.src) before it can be used in source code. Instead,
use a script to define these via magic comments at the point of use.
This hopefully will encourage creating new classes as needed.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
* CPPFLAGS is a user variable and should be respected
when compiling .c files. Think of -D_FORTIFY_SOURCE=2.
* Pass ALL_CFLAGS when linking too. This is recommended
for certain edge cases (-flto)
* Use DESTDIR instead of INSTALLROOT for staging dir
Every other build system (Automake, CMake, Meson) uses
DESTDIR. This integrates better into distro and other
build systems that have standard hooks for DESTDIR.
* $(MAKE) -C <dir> is better than cd'ing into a <dir>
* Use Autoconf's ${docdir} and ${htmldir} for installing
the documentation. This makes handling documentation
easier and respects user choice.
Signed-off-by: David Seifert <soap@gentoo.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Add a file local.css which is referenced *after* nasmdoc.css, thus
overriding the latter. This file intentionally has no actual content,
which means it can be overridden locally for any desired content,
e.g. indexing into web fonts or overriding any of the style.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The table of contents and index needed rework to be valid (X)HTML.
The TOC in particular needed some fairly significant rework - it is
supposed to be an ordered list, after all.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.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>
An uncompressed PDF is about twice as big, but if one is using an
external compression program (e.g. .pdf.xz) it compresses far better.
Use it for the RPM specfile.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
There is no sane reason to use nasmdoc.ps over nasmdoc.pdf since, oh,
about 20 years. nasmdoc.ps doesn't embed the fonts (and if it did, it
would be very large, whereas nasmdoc.pdf only contains the characters
we explicitly need), and support for PDF is generally much better than
support for PostScript.
It also makes the distribution file smaller to not have two redundant
files.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Use the Adobe Source Sans/Code Pro fonts by default. They are Open
Source fonts by Adobe. However, since these fonts are quite large,
let them be an external dependency and do our best to try to find them
with whatever mechanism is available on the system for finding
standard fonts.
Also have a list of substitution fonts if necessary.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Make the tool write the output (especially HTML) in a specified
subdirectory directly, and make the tool create the subdirectory if it
doesn't already exists.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
We have separate invocations for the various PDF tools anyway. It
generates a slightly annoying error message, but makes some other
things a little easier.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The code to handle building in a separate directory had seriously
bitrotted. This contains a number of fixes to make it possible,
including bits like the documentation which never worked in the past.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
inslist.src is an intermediate file, it should be in "make clean"
rather than "make spotless"; otherwise it ends up in the xdoc tarball.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
For PostScript to PDF conversion, use whichever of "acrodist",
"ps2pdf", or "pstopdf" which we can find on the system. I haven't
tried either acrodist or pstopdf myself, only going my the
documentation, but prefer acrodist since it is claimed to produce
smaller output files than ps2pdf.
1. Allow included files in rdsrc.pl
2. New program inslist.pl to generate instruction list from insns.dat
3. Mark certain comments in insns.dat as documentation subheaders
4. Add Instruction List appendix to nasmdoc.src
5. Update build process to invoke inslist.pl
