Re: build system: devpdf/download regression

[Ingo Schwarze]

Hi Deri,

thanks for your extensive explanation.

Deri wrote on Thu, Jun 23, 2022 at 05:32:10PM +0100:
> On Thursday, 23 June 2022 14:05:29 BST Ingo Schwarze wrote:

>>  1. Define a configuration variable.
>>  2. Unconditionally set that variable to a sane default value,
>>  3. Run some autoconfiguration tests that change configuration
>>  4. Use the configuration variable from source files during the

> You are positively correct.
> You can tell I have never looked after a big project!

I believe the above configuration scheme is also useful for
small projects (like groff or mandoc) and not only for large
projects (like texlive or mozilla or gnome).
Myself, i resent even looking *at* large projects,
let alone looking *after* them...  ;-)

> In the same way that the choice of URW directory is passed into 
> Foundry.in, although I would prefer separate variables, one for
> the users choice and one for the static paths.

I didn't make make up my mind whether that is a good idea, it may
or may not be.

In general, i would recommend differentiating configuration variables
by functionality.  For example, if all you need is one font path,
i would expect having one variable to configure it.  Two variables
would make sense to me if you have two different purposes or tasks,
for example, on the one hand a font path that gs(1) and groff *read*
already installed fonts from, and on the other hand a directory
that groff *writes* its own font-related files to.

But it would seem unusual to me to differentiate a configuration
variable according to the *source* of the information.  For
example, if components of the font path can come from three sources,
 1. a static list of directories that you collect over the years
    by talking to people using different operating systems;
 2. autoconfiguration results, for example from `gs -h`; and
 3. user configuration, for example from a ./configure option
then i would still expect one single variable since the whole
point of autoconfiguration is overriding or supplementing static
defaults and the whole point of user configuration id overriding or
supplementing both.

What would be the point of splitting the variable according
to the source of information?  (There may well be a point
that i'm still missing.)

[...]
> If I get the chance, as I've got a version of ghostscript with separate
> font  files, I'll do an strace on file openings to see if it actually
> loads the files if it has not been told to embed all fonts, my hunch is
> that it does not need to access the font unless it needs to embed a font
> which is not supplied by the postscript or pdf file it is distilling.

While this may be an interesting question to you, i don't think
it affects how things should be installed.  No doubt embedding a font
in the output files that isn't already embedded in the input files is
functionality that gs(1) needs to provide.  So the needed fonts
need to be
 * embedded via %rom% (as currently done on OpenBSD) or
 * installed as separate files as part of the main ghostscript package or
 * installed as separate files in a separate package (also provided
   by OpenBSD) that the main ghostscript package requires as a
   dependency (which OpenBSD does not currently require, but that's
   OK for now because %rom% is being used)

> If the results of gs -h include the text %rom%

They do on OpenBSD.

> I believe this means some files have been baked in, but you should
> talk to the ghostscript packager. One wrinkle, if you go with just
> one copy of the fonts and use symlinks is that ghostscript uses
> different names for the fonts than the old ms-dos names.

Since there are quite a few aspects to consider (including
different kinds of fonts even when considering default and URW
fonts only, and the naming business), i think i will focus on
polishing the groff port for now, to help making the groff
release as good as possible, and likely return to the question
whether and how the ghostscript package can be polished once
the groff release and the update of the groff port are done.

That seems best because i do not doubt that our ghostscript
ports in their current form provide everything groff needs,
so staying focussed is possible.

Yours,
  Ingo