While it further breaks RPM building, all AC_SUBST(HAVE_*) have been nuked.
When AM_SUBST_NOTMAKE, tell automake to not generate var = @var@ in
Makefile.in for qf specific vars (QF_SUBST is a wrapper for AC_SUBST that
also calls AM_SUBST_NOTMAKE).
Thanks to spirit for pointing that QF wasn't compiling with zlib 1.2.6
(archlinux, not yet in debian).
I was using gzFile as "gzFile *gzfile", but gzFile is already a pointer. In
older versions of zlib (including the 1.2.3 that's in debian), gzFile is
declared as a void *, and it seems that gcc is happy with assigning void **
to void *. However, in recent zlib, gzFile is now struct gzFile_s *, which
gcc is most definitely unhappy about assigning to struct gzFile **.
I just hope that either I had misread the type back when I wrote quakeio,
or that nobody is using such an ancient zlib.
And fix the macro's spelling, too :)
QF_PROCESS_NEED_subroutine needs too much knowledge to get the prefix
riight every time. Much easier to set it at invocation.
QF_PROCESS_NEED has been renamed to QF_PROCESS_NEED_LIBS and its guts have
been moved to QF_PROCESS_NEED_subroutine, with additional modifications to
allow QF_NEED to be used for other targets as well (eg, directories,
executables, etc).
This makes gib depend on gamecode, but removes the dependency on gib from
ruamoko. Unfortunately, carne now needs to be linked against gamecode even
though it never uses it.
Just about to do a release, and I realized windows users wouldn't have any
way of checking out the new renderer. I'll add wglsl when I get a chance to
do some testing.
o All instances of LIBADD/LDADD have a corresponding DEPENDENCIES
specificatiion.
o libraries now use a lib_ldflags macro to keep things consistent
o duplication of source/lib names has been minimized (particularly in
the libraries; more work needs to be done for the executables)
o automake spec blocks have been organized (again, more work needs to be
done for the executables)
The api hides all the gory details of message buffer setup and usage
(particularly the differences between writing and reading). Most
importantly, the api provides a safe way to read and write binary data
(always little endian).
