This is my literate programming support package.  Its main purpose is
to provide syntax highlighting in multiple source languages using
noweb, GNU make, and a number of other freely available packages.  It
can be configured to use one of several different highlighting
packages (listings, GNU source-highlight, André Simon's highlight),
and can produce PDF and HTML output in several different ways
(pdflatex, xelatex, noweb-l2h, tex4ht).

It also has a few side features:  attaching the noweb source to the
PDF and HTML output, providing parameterized chunks, some
auto-generated makefile boilerplate, automatic merging of multiple
noweb files (allowing creation of what I call "modules"), support for
out-of-order C (mainly by auto-generating prototypes), and some
support for separate user-level documentation (by re-inserting parts
of the main docs or tangled chunks, and for C, inserting formatted
function prototypes).

On the minus side, it does not provide automatic identifier indices in
any language, automatic chunk language detection, or much
customization (other than highlighting theme selection).  It is very
tailored to my own needs and aesthetics.

For details, read the source.  It's meant to be read, anyway.  On the
other hand, instead of reading the source code, you can just read the
users' manual:

   https://github.com/darktjm/literate-build/releases/latest/download/build-doc.pdf
   https://github.com/darktjm/literate-build/releases/latest/download/build-doc.html

Producing the PDF and HTML output from scratch is trivial if all of
the prerequisites are met, but rather than forcing you to read the
noweb source to find out those prerequisites, I have provided the PDF
and HTML output as well.  One of these is all you need, since they have
the source attached (and have instructions for detaching).  These are
available in the releases section:

   https://github.com/darktjm/literate-build/releases/latest/download/build.pdf
   https://github.com/darktjm/literate-build/releases/latest/download/build.html

The documentation referenced above is mostly the Usage section of the
code, split out into its own file using the documentation reinsertion
facility.  The source code for both the split out documentation and
the build system are attached to those files, so no further downloads
are required.

There are a few extra C utilities that I use in a lot of my other code
as well.  It's pretty poorly designed (at least namespace-wise), but
very convenient for me.  Read the source for details; it's shorter
than the build system's users' guide.  Again, these have their own
source attached, as well as the source for the build system.  However,
they do not have instructions on how to extract and build; see the
above for that.

   https://github.com/darktjm/literate-build/releases/latest/download/tjm-ext.pdf
   https://github.com/darktjm/literate-build/releases/latest/download/tjm-ext.html

In addition, the build system has a mechanism to create a tarball of
the extracted sources, which should no longer depend on the presence
of noweb.  This tarball is most useful if you actually want to compile
the tjm-ext library without using the build system from scratch:

   https://github.com/darktjm/literate-build/releases/latest/download/build-src.tar.gz

Don't bother with ada-build.nw, since it is a work in progress
abandoned years ago.  It does work with some of my old Ada sources,
but is mostly a non-functional repository for my old version 1 and 2
code.  The only reason it's here is that this is a mirror of my SVN
build directory, where that happens to reside.

As a side note, this is a copy of an SVN project.  I use the SVN Id,
Date, and Revision information in the printed output, as well as to
stamp every object file.  Linus says this is stupid of me**, so git
discourages this.  However, if you want your printed output to look
like mine, you'll need to expand the keywords.  I have found a project
which does this (https://github.com/turon/git-rcs-keywords), sort of.
I have included a copy of the (corrected and updated*) filters in
.git_filters; to use them, as per the original project's README, add
the following to ~/.gitconfig:

[filter "rcs-keywords"]
	clean  = .git_filters/rcs-keywords.clean
	smudge = .git_filters/rcs-keywords.smudge %f

After that, either clone a fresh copy, or force a checkout of all
noweb files.  I know nothing about git, so I have no idea how to do
that properly (not checkout -f, that's for sure), but this works:

  for x in *.nw; do /bin/rm $x; git checkout $x; done

The same is true for all of my other github-posted literate
projects.

* see https://github.com/darktjm/git-rcs-keywords

** http://www.gelato.unsw.edu.au/archives/git/0610/28891.html:
   "The whole notion of keyword substitution is just totally idiotic."
   "doing it should be in helper scripts or something"
   "[the Linux kernel's snapshot script] is how to do keyword
    substitution in a _sane_ way."
   "... keyword substitution is just stupid."
     You know what?  The latex rcs package parses svn keywords well and
     allows me to put the last checkin date and revision ID on my title
     pages without having to write a script for it.  I also like to
     store $Id$ in all object files, so that a "strings" will tell me
     the versions of all code in a binary.  Linus might have a point for
     the binaries, in that unlike SVN, you can store just one hash in
     one place, rather than in every file, but even then, I'd prefer
     the hash and date of the last modification in each file instead.
     Providing VCS info in the final output product has been a desirable
     property since time immemorial.  But yeah, I guess it's stupid to
     want to make it convenient.  After all, git was designed for Linux
     development, and other people using it is just silly.