[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #63824] revert recent change to skip tests at configuration time

From: Deri James
Subject: [bug #63824] revert recent change to skip tests at configuration time
Date: Tue, 21 Feb 2023 13:03:13 -0500 (EST)

Follow-up Comment #2, bug #63824 (project groff):

[comment #0 original submission:]
> The gropdf situation is harder.  The thing that can scotch its tests is not
missing commands but missing fonts.  There's no _easy_ way to tell from within
a test script whether gropdf is going to find Type 1 fonts it can embed in the
documents it generates.  (Locating them is a _complex_ process.)  And Deri are
still wrangling with testing issues anyway (see bug #63808).
> In the long run (groff 1.23.1?), maybe what we want to do is something Deri
wanted to do a long time ago, which is bust out part of BuildFoundries.pl as a
script that is runnable at configuration time (we depend on Perl anyway). 
That script can be the snout that sniffs out the presence of embeddable Type 1
fonts on the system.  Not only can we set shell variables that will inform the
user whether gropdf's functionality will be attenuated (as we already do), but
we can create artifacts in the build directory (at build time) that the gropdf
scripts can look for.  (We already have an Automake variable,
`HAVE_URW_FONTS`, that is produced by `AM_CONDITIONAL` in "configure.ac". 
Perhaps what we want is more like `HAVE_EMBEDDABLE_DEFAULT_FOUNDRY` and
Have you looked at the --check flag of BuildFoundries? It is intended to
report whether BuildFoundries will succeed in populating the download file in
devpdf. However, there is a chicken/egg problem, in order to be called from
configure it needs to be "made" i.e. populate @PERL@,
does it and made executable. I don't know if it is possible.

Currently it returns non-zero if a problem is found, but it would be more
useful to change it to return an integer 0..3 corresponding to the scenario
discovered. It could remove some duplicated tests in configure.
> The gropdf test scripts could then simply look for these artifacts in the
build tree, and continue or skip themselves as appropriate.
> But for groff 1.23.0, it might make more sense to just run the tests every
time and let them fail as we warned in ./configure output if the host
environment isn't ship-shape in the embeddable fonts department.
> None of this would prevent a build from being deployed elsewhere, or
Ghostscript and/or URW packages from being removed after a groff build, so
gropdf will still need to re-verify the availability of fonts to be embedded
every time it runs anyway.  And it does.  (Another thing Deri and I have
wrangled over is the wording of the diagnostics that happen in this scenario. 
:) )
> Maybe it doesn't even make too much sense to worry about users being alarmed
by test failures here.  Everybody's heard of "./configure && make && make
install".  Few seem to bother with having "make check" in there... :-/


Reply to this item at:


Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]