Re: install-font script (was: groff 1.23.0.rc2 readiness)

[Deri]

On Monday, 6 June 2022 06:38:00 BST G. Branden Robinson wrote:
> Just within the past couple of days, on this list, it came to light that
> our generation of Foundry files might be buggy, omitting the Ghostscript
> font search path.[2]

Hi Branden,

Since you have moved the discussion here, I will answer here as well.

> If "(gs)" is supposed to get replaced with the "gs -h" search path, I
> have bad news.
> 
> These lines in Foundry.in:
> foundry||(gs)
> foundry|U|(gs):@urwfontsdir@:/usr/share/fonts/type1/gsfonts:/opt/local/share
> /fonts/urw-fonts
> 
> end up looking like this in font/devpdf/Foundry.
> 
> foundry||(gs)
> foundry|U|(gs): :/usr/share/fonts/type1/gsfonts
> :/opt/local/share/fonts/urw-fonts # the URW fonts delivered with
> ghostscript (may be different)
> 
> The news gets worse.  The generated Foundry file I'm quoting is from my
> system's groff 1.22.4 installation.  (The Git HEAD version differs only
> in placing the comment differently, and lacking the spaces before the
> colons, both changes I made deliberately.)
> 
> In other words, if my assuption about "(gs)" handling is correct, this
> substitution has been broken for years.
> 
> Can you shed some light on whether my assumption is right?

Sorry, it is not. The token (gs) is not meant to be expanded by the build 
system, only 
@urwfontsdir@ which is provided by the configure flag --with-urw-fonts-dir. It 
is the 
BuildFoundry script which does the expansion of (gs), since if it is to be run 
as a stand-alone 
utility (as was my original intention) it needs to run the version of 
ghostscript on the users 
system, not the build system. I agree the scripts name is misleading, perhaps 
BuildGropdfDownload would have been better.

> This is another sticky wicket.
> 
> We need to generate "Foundry" and "download" files for the build system
> so that we can run gropdf at build time to produce artifacts like
> groff-man-pages.pdf (a pretty new thing), automake.pdf, and several
> examples for mom(7).
> 
> However, when cross-compiling, the _host_ system is not the _build_
> system by definition.  So if someone is trying to cross-compile groff
> for a Windows host on a GNU/Linux build machine (an eminently reasonable
> thing to do since, yuck, who would want to develop software on
> Windows?), _if we were to ship_ the BuildFoundries script, it would use
> the wrong path separator character.

I think it is a batters wickets and your googlies will be unsuccessful!

BuildFoundry gathers a list of directories and a list of files and searches 
each directory one by 
one looking for a recognised file. It never passes the list of directories to 
the O/S so the choice 
of separator is moot. It is things like PATH which require careful choice of 
separator based on the 
host O/S.

Cross compiling may be problematical, but not for using the the wrong path 
separator. In your 
example, build linux/target windows, the BuildFoundry script would produce a 
download file 
which would build the "artifacts" you mention, but I am unsure whether the 
delivered download 
file would suffice for gropdf on windows, it may require a separate run of the 
script on the 
windows machine after install. It probably depends on whether groff is run 
natively or under 
something like cygwin. I suspect that if ghostscript is run natively on windows 
you may see paths 
such as c:\... which would scupper your change to using just ":" as the split 
character for parsing 
the output of gs -h. Perhaps this is why ghostscript are using " : " as a 
visual indicator to separate 
the paths in the gs -h list.

As I suggested it would be helpful if you are able to run gs -h on a windows 
box under cygwin 
and natively, the output would help us.

> I assume this is why our Makefile.am has this.[3]
> 
> [[
> #`RT_SEP' is the operating system's native PATH SEPARATOR CHAR, which
> #is to be used in runtime PATHs compiled into groff executables.
> RT_SEP=@GROFF_PATH_SEPARATOR@
> 
> #`SH_SEP' is a alternative PATH SEPARATOR CHAR, to be used in shell
> #scripts and makefile rules; it may be the same as `RT_SEP', but,
> #particularly in some Microsoft environments, it may differ.
> SH_SEP=@PATH_SEPARATOR@
> ]]
> 
> If we want to use BuildFoundries both at build time and also to ship it,
> the script is going to need to be parameterized in the path separator;
> i.e., we're going to need to add a command-line option to select it.
> (Well, we could trick the script out to query the runtime environment
> but I think an option is simpler to implement and for everyone to
> understand.)

No, path separator is not relevant to BuildFoundries.
 
> On the gripping hand maybe this issue is void, because it seems everyone
> who has ever had anything to do with groff on Windows has lost interest;
> they quit replying to emails in early 2019.  My guess is that "Windows
> Subsystem for Linux 2: Ubuntu Boogaloo" is responsible for this;
> possibly everyone who cares to run groff on Windows just does it in this
> ersatz virtual machine.
> 


> I can only guess we haven't heard more complaints because this approach
> only supports Type 1 fonts and we already support most of the Type 1
> fonts people are interested in.

Another guess would be that you misunderstood that the (gs) token in Foundry.in 
is not 
expanded in the transition to Foundry, but is expanded when BuildFoundry is run.