Re: build system: devpdf/download regression

[Deri]

On Sunday, 26 June 2022 13:11:12 BST Ingo Schwarze wrote:
> Hi Deri,
> 
> thanks for your extensive explanation.
> 
[...]
> > 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.)

Hi Ingo,

I was considering priority, I wanted to ensure Users choice came first. 
However, this can be achieved in one variable so long as users choice is 
first, followed by the static paths, so I agree it makes sense as one 
variable.

[...]

> 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

Cheers

Deri