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_EMBEDDABLE_URW_FOUNDRY`.) 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@, @GROFF_GHOSTSCRIPT_INTERPRETERS@ and @PATH_SEPARATOR@ with sed or whatever 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: <https://savannah.gnu.org/bugs/?63824> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/