Hi Barak,
thank you for forward-porting and reworking your Debian patches (7 items),
and for the clear patch headers: describing the problem separately from the
solution made the review a lot easier. All items are dealt with in SVN 2163.
Before going through the patches, let me correct something I said earlier.
I wrote that my aim is to change the GNU APL sources so that Debian does not
need to patch them. What I should have said is: so that Debian does not need
to patch the C++ sources. The reason is a difference between Debian's build
strategy and GNU APL's:
- Debian minimizes the build artifacts in a package, at the expense of
more build dependencies. It can, for example, safely assume autoconf,
automake and makeinfo (as the GNU project does), backed by its
dependency
tracking.
- GNU APL minimizes the build dependencies, at the expense of shipping
build artifacts. apl.info, apl.html, configure, Makefile.in etc. are in
the tarball and in the Savannah SVN, so that a user's "svn up" brings
them in and building GNU APL needs neither autoconf/automake nor
makeinfo. This is non-standard, but it does not hurt either.
I therefore divided your patches into two classes:
1. source code fixes, platform issues etc. These I fix in the GNU APL
sources, so that you can drop the patches.
2. Debian build related patches. These remain on your side; Debian is
your turf, not mine, and I would prefer not to touch how non-Debian
builds work.
Summary
-------
Fixed: 4 (0003, 0004, 0006, 0007)
Fixed with exception: 1 (0001)
Not a bug: 2 (0002, 0005)
Fixed
-----
0003 install-dirs-at-make-time: applied as is. The apl_DIR__ macros are
now passed in AM_CPPFLAGS and gnu-apl.d/preferences is generated at
make time. I tested a build with --prefix=/usr
--libdir='${prefix}/lib/x86_64-linux-gnu' --sysconfdir=/etc and
make install DESTDIR=...: apl --show_lib_dir and LIBREF-3/4/5 now
point to where wslib3-5 and the native libraries are installed. I
also made the windows-installer-stage target build preferences
first, since configure no longer creates it.
0004 Quad_FIO-screen-size-no-tty: applied as is. In addition, ⎕FIO ¯9
no longer runs off the end of the function on MinGW (it now returns
0 there).
0006 pkg-config-for-host: applied as is. aclocal.m4 (which is in SVN)
now contains the pkg.m4 macros, so pkg.m4 is only needed to
regenerate it.
0007 vpath-builds-anywhere: applied, except for README-12-vpath-builds:
the make target VPATH_clean still exists in trunk, so the README now
mentions it as an alternative to 'make distclean'.
Fixed with exception
--------------------
0001 doc-info-html: not applied, since building the manuals from their
.texi sources is the Debian strategy (class 2). However, the problems
that you describe were real, and I fixed them in a way that keeps the
shipped manuals:
- ./configure checks for makeinfo (AM_CONDITIONAL apl_MAKEINFO).
- With makeinfo, apl.info, apl.html, libapl.info and libapl.html are
rebuilt if their .texi source is newer, and a makeinfo error stops
the build (no more "|| touch").
- Without makeinfo, the shipped files are used (with a warning if the
.texi source is newer). If a shipped file is missing, then this is
an error instead of an empty file.
- make install takes the .info files from the build directory if
they were rebuilt there (VPATH build), and otherwise from $(srcdir).
- doc/DALY/apl-library.info is handled the same way (it had no build
rule at all before), and uninstall removes apl-library.info (it
removed apl.info and libapl.info before).
Since you import the sources without the pre-built manuals and have
makeinfo, the unpatched Makefiles should now build all of them for
you. Whether you still need 0001 then depends only on its other
changes (info-in-builddir, not installing the .texi files), which
are up to you.
Not a bug
---------
0002 no-debian-subdir and 0005 no-Bible-preview: these are Debian
specific (class 2) and stay with you, as you suggested. Upstream
keeps installing HOWTOs/Bible. Note that the packaging directory in
trunk is now called deb/ (not debian/), so it should no longer
clash with
your debian/ directory.
Best Regards,
Jürgen
PS: The analysis of your report and the resulting changes were made with
the help of Claude Code (Anthropic). All changes were reviewed by me and
verified against the GNU APL testcases before being committed.
On 11/5/26 17:03, Barak A. Pearlmutter wrote:
Okay Jürgen, I just uploaded a version to debian based on the current
svn trunk tip as exposed on the savannah git repo.
Thanks for merging all those earlier patches, or fixing the issues
some better way, as the case may be.
I've forward ported the remaining patches, and reworked them, and
added some more.
https://salsa.debian.org/debian/gnu-apl/-/tree/debian/debian/patches
The patch headers should describe what's going on for each one. I
tried to first describe the issue, then list alternative solutions,
then describe the solution used. That way if the particular solution
seems bogus you should still have a clean problem description.
Patches 0002 and 0005 are debian-specific (sort of, I guess) so you
might want to ignore them.
Most of these are build script stuff.
Cheers,
--Barak.
