groff
[Top][All Lists]
Advanced

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

Re: build system: devpdf/download regression; was: groff man(7) `B` macr


From: G. Branden Robinson
Subject: Re: build system: devpdf/download regression; was: groff man(7) `B` macro...
Date: Sat, 18 Jun 2022 15:06:48 -0500

Hi Ingo,

At 2022-06-18T19:16:10+0200, Ingo Schwarze wrote:
> I have made a bit of progress with these.  I now suspect both are
> related to each other and not limited to any specific implementation
> of make(1).

Thanks for digging into this.  I think you uncovered not a simple
accident, but an oversight on my part when I refactored the build.

I did not consider, and did not test, the scenario where the build and
deployment systems differ, and the latter was more capable than the
former.

> Let's see, how is font/devpdf/download supposed to get built?
> 
> We have this in font/devpdf/devpdf.am, and using grep(1), i suspect
> it is the only reason why it might get built:
> 
>   font/devpdf/stamp: font/devpdf/DESC font/devpdf/download \
>     $(devpdffontenc_DATA) $(devpdffontmap_DATA) $(devpdffont_DATA)
>         $(AM_V_at)>$@

Yes.  That was deliberate on my part.

> So what asks for building font/devpdf/stamp?  Grepping again, i found
> these and only these consumers:
> 
>   In contrib/mom/mom.am:
>     if USE_GROPDF
>       MOMPROCESSEDEXAMPLEFILES = \
>       [... various *.pdf files ...]
>     endif
>     [...]
>     $(MOMPROCESSEDEXAMPLEFILES): $(MOMNORMALFILES) \
>       groff troff gropdf pdfmom penguin.ps penguin.pdf font/devpdf/stamp
> 
>   In contrib/sboxes/sboxes.am:
>     if USE_GROPDF
>     sboxespdfdocdir = $(pdfdocdir)
>     nodist_sboxespdfdoc_DATA = $(sboxes_builddir)/msboxes.pdf
>     endif
>     [...]
>     $(sboxes_builddir)/msboxes.pdf: $(sboxes_builddir)/msboxes.ms \
>       $(dist_sboxestmac_DATA) groff troff gropdf font/devpdf/stamp
>         $(GROFF_V)$(DOC_GROFF) -M$(sboxes_srcdir) -ms -msboxes -Tpdf \
>           $(sboxes_builddir)/msboxes.ms > $@
> 
>   In doc/doc.am:
>     PROCESSEDFILES_DEPS_PDF = groff troff gropdf font/devpdf/stamp
>     [...]
>     if USE_GROPDF
>     $(PROCESSEDDOCFILES_PDF): $(PROCESSEDFILES_DEPS_PDF)
>     endif
> 
> All consumers appear to be conditional on USE_GROPDF.
> Consequently, since i don't want our groff package to depend
> on ghostscript and friends and hence have this in my ports build script,
> 
>   # Our groff port needs to be lightweight because a few very basic
>   # ports still depend on it for building their manual pages.
>   # In particular, avoid dependencies on the following heavy ports:
>   CONFIGURE_ARGS += --without-libiconv-prefix  # converters/libiconv
>   CONFIGURE_ARGS += --without-gs               # print/ghostscript
>   CONFIGURE_ARGS += psselect=missing           # print/psutils
>   CONFIGURE_ARGS += PDFFONTS=missing \
>                     PDFIMAGES=missing \
>                     PDFINFO=missing            # print/poppler-utils
> 
> i intentionally end up with
> 
>   configure: The programs 'gs', 'pnmcrop', 'pnmcut', 'pnmtopng',
>    'pnmtops', and 'psselect' were not found in $PATH.
> 
> and
> 
>   config.log:USE_GROPDF_FALSE=''
>   config.log:USE_GROPDF_TRUE='#'
> 
> and
> 
>   #MOMPROCESSEDEXAMPLEFILES = [...]
>   #nodist_sboxespdfdoc_DATA = $(sboxes_builddir)/msboxes.pdf
>   #$(PROCESSEDDOCFILES_PDF): $(PROCESSEDFILES_DEPS_PDF)
> 
> in the generated Makefile, and it looks like in the end of the day,
> nothing whatsoever asks for building the font description files
> for devpdf.

Yup.  This is all entirely consistent with what I had in mind, except
for one wrinkle.

> The mistake here might be that the groff build system only regards
> the devpdf font decription files as prerequisites for building
> PDF documentation - but in addition, they should also be considered
> part of the devpdf infrastructure to be installed in their own
> right, no matter whether they are used during the build.

Right.  I didn't consider the scenario where running gropdf would be
impossible on the build host, but might work on a host to which the
installed files had been deployed.

> On a tangent, i suspect similar problems may be hiding elsewhere
> that will bite people who disable (or lack) other features in their 
> system that i left enabled.  That is, some integral parts of
> groff only being built because some optional stuff (like building
> documentation in an optional format) depends on them.
> But auditing for that kind of problem is hard because there are
> so many *.am files scattered around the tree and the automake
> infrastructure involved makes reading them a non-trivial task.

It's not _too_ hard because as a rule we've controlled the number of
places where this happens.  The main variables are (1) the generated
formats of our Texinfo manual, which I've mainly foreclosed by shipping
them all with the distribution archive; (2) the PDF output driver, as
you note; and (3) the HTML output driver, which similarly depends on
device and font description files to be generated at build time but,
even if they are, may not be able to run successfully because of a lack
of support tooling on the build host.

I think these are superable problems.

> The quick and dirty patch appended below fixes the immediate problem
> in my partciular setup.  Now all the expected devpdf files get
> built and installed, including the "download" file and the individual
> font description files like TR, TB, CR and so on.

Importantly, this should ship the U-* font descriptions if they are
present and not if they aren't.

This does pose a difficulty for your build scenario; you must decide
whether you want to cater to users wishing to run gropdf using the URW
fonts, or not.  If so, you will need to add a build dependency on them.
If not, those users will have a tough time until we can get user-facing
tooling (the infamous "install-font" problem) fully developed and
supported.  The short path is probably for them to build groff from
source and re├źnable some of the stuff you're turning off.

> But i'm not convinced this is the right way to fix it.
> How do i properly tell the groff build system "i want this target
> built unconditionally"?
> I wish this build system were be less complicated.
> We are slowly making progress in that direction, but with automake,
> i fear it will always remain a maze.  :-/

Your patch seems valid and minimally intrusive to me; it may look a
little bit weird (for an Automake file), but the circumstances leading
to it are weird.  Normally I think Automake would require us to store
the names of the files to be installed in one of its magical variables,
but that's necessary here because our Automake file _already_ goes
behind its back with an install hook and a `for` loop.

> diff --git a/font/devpdf/devpdf.am b/font/devpdf/devpdf.am
> index 363d4cdd0..64ed657d4 100644
> --- a/font/devpdf/devpdf.am
> +++ b/font/devpdf/devpdf.am
> @@ -51,6 +51,8 @@ EXTRA_DIST += \
>    font/devpdf/Foundry.in \
>    font/devpdf/util/BuildFoundries.pl
>  
> +all: font/devpdf/stamp
> +
>  font/devpdf/enc/text.enc:
>       $(AM_V_at)$(MKDIR_P) $(top_builddir)/font/devpdf/enc
>       $(AM_V_at)cp -f $(top_srcdir)/font/devps/text.enc \

Regards,
Branden

Attachment: signature.asc
Description: PGP signature


reply via email to

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