Re: build system: devpdf/download regression

[G. Branden Robinson]

Hi Deri,

At 2022-06-22T21:30:25+0100, Deri wrote:
> I think I have sussed what might be happening. In the port build the
> standard fonts get built because of the addition of
> /usr/local/share/fonts/ghostscript to the Foundry file yesterday. None
> of the U fonts get built because this make rule deletes half the
> foundry file before BuildFoundries is run:-
> 
> font/devpdf/Foundry: $(devpdf_srcdir)/Foundry.in
>       $(AM_V_at)$(MKDIR_P) $(top_builddir)/font/devpdf/
> if HAVE_URW_FONTS
>       $(AM_V_GEN)sed "s|[@]urwfontsdir[@]|$(urwfontsdir)|" \
>         $(devpdf_srcdir)/Foundry.in >$@
> else
>       $(AM_V_GEN)sed "/BEGIN URW/,/END URW/d" \
>         $(devpdf_srcdir)/Foundry.in >$@
> endif

Whoops.  This sed-foolery was me, not very long ago.[1]

> So if HAVE_URW_FONTS is not set when configure is run the U- fonts
> will not be created. When configure is run the part which is meant to
> check for the presence of the URW fonts, starts with:-
> 
>   groff_have_urw_fonts=no
>   if test "$AWK" != missing && test "$GHOSTSCRIPT" != missing
>   then

This logic is much older, and went out with groff 1.22.4.

> So it does not even do the tests if ghostscript is set to missing,
> which I believe is the case with the port version. So even if you
> supply the URW fonts directory to configure this directory is not
> tested and HAVE_URW_FONTS remains false. If ghostscript is missing it
> should just not run gs -h as part of collecting paths to search, but
> still do the search on the remaining paths.

"it" meaning the BuildFoundries script?

> > Those files below http://schwarze.bsd.lv/tmp/urw/
> > of which i did not upload new versions did not change.
> > 
> > > So you shouldn't need the --with-urw-fonts-dir flag any more.
> > 
> > To make things work without --with-urw-fonts-dir, i need the
> > additional patch shown below.  Otherwise, ./configure won't
> > find them, and BuildFoundries comes too late to fix that.
> > Do you think i should commit and push that additional patch?
> 
> I think the tests for awk and ghostscript need to just apply to the
> line which uses those programs, not the whole section, but the patch
> is good.

I'm happy to change GROFF_URW_FONTS_CHECK in this manner, but I'll hold
off until you or Ingo pushes his patch.

Can you confirm that the "sed-foolery" should stay, if we improve our
search for the URW fonts in the first place?

> > It's hardly ideal to have this path written out verbatim at two
> > independent places: we just experienced how it *will* get out of
> > sync.  But let's improve one thing at a time.
> 
> I did add a --check flag to the BuildFoundries program, which checked
> for all the required fonts and returned an exit status, but I hadn't
> really thought it through, a bit of chicken and egg situation! I
> suspect a new file containing possible paths which BuildFoundries
> accesses, or the configure test pulls the paths from Foundry.in rather
> than having them hard coded.

This seems like an easy improvement as well--another piece of oddball
data we can keep in font/devpdf.

> Since the fonts don't appear in any of the directories yielded by "gs
> -h" means that the person porting ghostscript for your system decided
> to use the option to have the fonts embedded in the gs executable
> (%rom%) rather than as separate font files. I'm not sure if there is
> much advantage with modern hardware. Here's a chap asking where the
> font files have gone:-
> 
> https://stackoverflow.com/questions/38331893/ghostscript-fonts-folder-removed-from-later-versions

I wonder if we should detect this and warn about it.  I've gotten pretty
familiar with our Autoconf macros.

Regards,
Branden

[1] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=bf25f7ebf35c9ab384455edb1612494b4af46817

signature.asc
Description: PGP signature