Hi Branden,
G. Branden Robinson wrote on Sat, Jun 18, 2022 at 10:40:46AM -0500:
> At 2022-06-17T20:53:13+0200, Ingo Schwarze wrote:
>> during the testing described below (which i foolishly expected to
>> be minor), i tripped over several new candidates for regressions
>> that look unrelated. This is not a serious report yet, i'll have to
>> investigate in more detail and then report properly. The candidates
>> include the following effects that i saw in my usual test setup:
> The PDF ones are surprising to me. But not inexplicable--Deri and I
> have both done recent work in this area. (The problems are likely
> solely my fault, though.)
>> * The build died when trying to install font/devpdf/download
>> because the file was never built and consequently didn't exist.
> My surmise is that this arises from commit 6e62be835d. I'll try an
> out-of-tree build with MAKE=bmake and see if I can reproduce it.
>> * The PDF font description files (font/devpdf/TR and friends)
>> no longer got installed.
> I don't have a clear hypothesis for this one. I can say it's a little
> trickier to deal with because the set of font description files for the
> PDF output driver is dynamically generated, and differs depending on the
> availability of the URW font files. This is unlike all of the other
> output drivers. I'll take a closer look; maybe BSD Make will sniff this
> one out too.
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).
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)>$@
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.
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.
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.
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.
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. :-/
I won't mix the discussion about the .TH font regression
into this message but address the rest of your reply separately.
Yours,
Ingo
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 \
