The PT-E560BT stays busy about 2.2 s after even an 8 mm label, so the
1 second default timeout cannot succeed on a job sent straight after
another: printing five chained labels gives a strip carrying three of
them. ptouch-print reports the timeout and exits non-zero correctly every
time, but no amount of waiting helps when the default is below the
printer's fixed overhead.
Add a trailing min_timeout to the device table. Every other row keeps its
initialiser and gets 0, which resolves to the old default of 1; only the
E560BT carries a value. An explicit --timeout always wins.
Raising the global default would also be defensible: ptouch_getstatus()
returns as soon as the status arrives, measured 0.13 s with --timeout 30
against 0.14 s with --timeout 1, so a higher ceiling costs nothing on a
printer that is ready. But that is a judgement about printers I do not
have, so this keeps it to the one that was measured.
On macOS with Homebrew's argp-standalone, Findargp's link test for
argp_parse fails with an undefined strchrnul, because libargp.a itself
references that GNU extension and the platform has none. The module then
stops with "does not have a symbol named argp_parse", which is not what
is wrong.
Probe for strchrnul first (with _GNU_SOURCE, so glibc answers correctly).
Where it exists, the test is unchanged. Where it is missing, run the same
argp_parse test with a local definition of strchrnul, and have ptouch-print
supply that definition for the real build.
On glibc nothing changes: the probe finds strchrnul and the original test
runs. Checked on Debian stable in the same session.
pkg_check_modules gives both LIBUSB_LIBRARIES (bare names, -lusb-1.0) and
LIBUSB_LINK_LIBRARIES (absolute paths). Passing both links libusb twice,
and the bare name only resolves when libusb is in the default library
search path - which it is on Linux and is not under Homebrew on macOS,
where the link fails with "library not found for -lusb-1.0". The full
path alone is enough everywhere.
Kevin Bradenstein