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.
