Re: build system: devpdf/download regression

[G. Branden Robinson]

Hi Ingo & Deri,

At 2022-06-26T17:16:44+0100, Deri wrote:
> > 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.)
> 
> 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.

Where do we stand on this right now?  Is this something I can help move
along?

It occurs to me that could have a single text file in the source tree
which stores, one per line, a list of directories known to be useful
historically for locating PostScript fonts (Ingo's #1 above).

BuildFoundries and groff.m4 could each read that, turn it into a
$SEP-arated search path, and prefix it successively with directories
scraped out of `gs -h` output and the user's choice of
`--with-urw-fonts-dir`, if any.  Too bad it would be a pain to drop
duplicates from the search path without disordering it.

My apologies for being a bit confused and uncertain; this aspect of
groff is in flux right now but I think we're making it better.

Regards,
Branden

signature.asc
Description: PGP signature