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.
The chocolate-{server,serup}.6 manpages are static and not auto-generated, so they do not get renamed when the @PROGRAM_PREFIX@ variable changes. This breaks the Make rules for forks, which will have to create their own server and setup manpages anyway. This reverts part of commit 08ad5553 by myself which introduced the issue.
Fixes https://github.com/fabiangreffrath/crispy-doom/issues/2
Add back to binaries that are built and installed as _SCRIPTS targets.
Copy instead of symbolic linking, the files are needed as binary copies anyway to allow for separate packaging of the game engines.
1) Instead of copying chocolate-setup into chocolate-{doom,heretic,hexen,strife}-setup,
respectively, check in configure for symbolic linking and use that if available
(falls back to "cp -pR" if not).
2) Add $(icons_DATA) to CLEANFILES so they get removed in clean phase; they are
generated from doom-png and setup.png, respectively.
3) Consistently use @PROGRAM_PREFIX@ instead of the hard-coded "chocolate-" in
the rules for the man pages.
4) Generate one man page for each setup program by symbolic linking of
chocolate-setup.6 (see 1), add them to the list of installed man pages and
to CLEANFILES.
5) Remove the redundant $(EXEEXT) suffix from the setup binaries (they were missing
for execgames_PROGRAMS, anyway)
