This got broken by some recent changes. As part of this, remove a
now-deleted wiki page and also add a Makefile target to build the page
(for Doom, at least).
I have a habit of doing this in shell, and Make is not shell. It was
overall harmless, but it looks cleaner when building to not see
"-D_WIN32" (quotes included) in the commands being run.
The text output mode included useless whitespace at the end of lines
and also occasionally generated lines containing nothing but
whitespace. Clean up the code that generates text output and fix
these bugs.
The "general options" section of the manpage(s) has become quite
cluttered, and some of the options are obscure things most people don't
need to know about. Move the really obscure ones into their own category
near the end of the manpage, and factor out the options used when
starting a game from the command line into their own section as well.
Also add some missing doc comments for Hexen command line options.
The ftp.idsoftware.com server died several months back. Some context:
<https://www.doomworld.com/forum/topic/96999-rip-ftpidsoftwarecom/>
Instead, point at the mirrors found in the idgames repository, using
the gamers.org version since this is the canonical copy everything else
mirrors from. Unfortunately it's not possible to point at the Doomworld
idgames interface since the patches don't appear in the database there.
Build chocolate-game-setup.6 directly instead of building
chocolate-setup.6 and copying it to for each game. Apply
substitutions to the template text to replace Chocolate,
chocolate etc., as well as substituting the proper default
cfg equivalent (e.g. heretic.cfg) for each game.
Move to a "substs" hash in docgen which contains pairs of strings
to substitute. Populate @GAME@, @GAME_UPPER@ and @CFGFILE@ based
on the game supplied via -g.
Make the corresponding substitutions in default.cfg.template. Now
all of {default,heretic,hexen,strife}.cfg.5 are correct for the
respective game.
Define and pass LONG_EXE_NAME and LONG_GAME_NAME within the
controlling Makefile when generating INSTALL.*, instead of
deriving their values within the template depending on whether
DOOM/HERETIC/HEXEN/STRIFE are defined.
This means we can incorporate the values from @PROGRAM_PREFIX@
and @PACKAGE_SHORTNAME@, instead of hardcoding chocolate- and
Chocolate, respectively.
Convert chocolate-setup.6 into a template file and generate outputs
based on @PROGRAM_PREFIX@.
Add @PACKAGE_SHORTNAME@ to the list of parameters handed to docgen
and make appropriate substitutions in the manpage templates.
This is in order to better support derivative engines.
Rework the manpages to be parameterized with @PROGRAM_PREFIX@ and
@PACKAGE_NAME@. Alter the `docgen` generator to substitute those
parameters. Supply those parameters via the autofoo Makefile.
Adjust the fixed path chocolate-server.6 to be generated from
server.template, similar to doom.template -> chocolate-doom.6.
Further work is required, not least renaming chocolate-setup.6,
but several further parameterizations.
Introduce a new PROGRAM_SPREFIX variable in configure.ac, which is
basically identical to PROGRAM_PREFIX but without the trailing hyphen.
PROGRAM_PREFIX was also redefined so that it bases its name from
PACKAGE_SHORTNAME, reducing the number of hardcoded chocolates in the
source.
My last commits broke functionality for Python2, but it's relatively
simple to fix.
open() becomes io.open() -- it effectively does nothing for Python3,
but for Python2 it uses a backported version of the open() call.
Python2 uses bytes and strings interchangably, but I needed to use
stdout.sys.buffer for writing arbitrary bytes data to stdout.
Conditionally call the appropriate stream depending on Python version.
When encountering non-ASCII UTF-8 characters in source files (as
exists in Crispy Doom), the Python scripts would fail to work with
a UnicodeDecodeError if the locale was not a UTF-8 one (eg, the C
locale as encountered in chroot build environments).
Let's just use UTF-8 on both open() and replace print() statements with
sys.stdout.buffer.write(). This guarantees that all input and output is
UTF-8 regardless.
For out-of-tree builds we must specify the full paths to source files
using $(srcdir). Do this for all the template files and clean up some
of the confusing and inconsistent usage of source dir paths already in
place.
When interpreting a template file that uses the @include statement, we
must read the included file from a path relative to the first template
file, rather than relative to the working directory when invoking the
script. This will allow us to do out-of-tree builds.
The function requires two arguments: an organization name and an
application name. Let’s set the organization name to an empty string.
This will not cause issues on POSIX-compliant systems, and hopefully
not on other kinds of systems too. This just avoids an extra
directory to the configuration path.
This should pull Chocolate Doom into compliance with the XDG Base
Directory Specification, resolving #597.
Doomworld is now available over https: so there's no reason to link
to unencrypted http: URLs (which are just redirect anyway). Also the
idgames interface URLs have changed.
Versions of make other than GNU make don't support automatic variables
in explicit rules, only in suffix (implicit) ones.
This fixes the build on FreeBSD (and possibly other BSD variants), which
was failing with errors like:
cp chocolate-doom-setup
usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-alpvx] source_file target_file
cp [-R [-H | -L | -P]] [-f | -i | -n] [-alpvx] source_file ... target_directory
*** Error code 64
Stop.
Only one for all four games and only static for the time being.
In the long term, we should modify the docgen script to emit the
possible valid command line parameters and their additional options
and thus create separate bash-completion scriptlets for all four
games.
We now search in a bunch of different directories in order to find
IWAD files to use to play with, and the logic is a bit complicated.
Add some hopefully friendly documentation to explain where people
can put their IWAD files to play with.
Part of #597.
