Follow-up Comment #34, bug #67207 (group groff): On Tuesday, 24 June 2025 01:15:06 BST G. Branden Robinson wrote: > Follow-up Comment #33, bug #67207 (group groff): > > Resuming the conversation about build infrastructure stuff. > > Deri responded to me in an email: >>> (font/devpdf/download): Set write permission on the target to work >>> around GNU Automake "distcheck" feature that makes make(1)-generated >>> files read-only; however we want "BuildFoundries" to rewrite the file >>> in place. >> >> A while ago you changed it from writing download directly to > > writing >> to >> download.tmp which >> is then "mv"ed. > > I _think_ what's happening--but I haven't verified this or dug into Automake > internals to try to grasp what's going on--is that because > "BuildFoundries.pl" rewrites the "download" file by "clobbering" it, that > triggers the overwrite warning due to the permissions Automake sets to test > the distribution archive. > > We use the "mv [email protected] $@" technique in other places without provoking this > issue, at any rate, so the foregoing is my guess.
Almost there. mv [email protected] $@ works great if $@ does not already exist with read- only permissions, similarly copying download.in works great if the mv has not already happened. With 16 cores make -j would sometimes work (when the cp and the mv finished before the chmod -R a=r hit). >> Yes it could be a separate target, but I would prefer a pfb file (more >> compact, gropdf is slow enough already). So maybe StandardSymSL.pfb.in >> generates (cp -u) StandardSymSL.pfb. >> SS does not actually need a separate rule, a change to foundry.in could >> take care of it, but if you intend to retire BuildFoundries transferring >> all the logic to devpdf.am it is probably not worth it. > > Okay. Adding the low-hanging fruit as a plan for this ticket. > > I don't have any short-term aim to retire "BuildFoundries.pl", but for > build-related jiggery-pokery I'd like to do as much in _make_(1) targets as > possible. > > By contrast, we can still use _pfbtops_ to generate a PFA from > "StandardSymSL.pfb", but we don't have to name the PFA in the "download" > file. Not doing so makes the exercise a bit of a digression from > "devpdf.am"'s mission, but I like the idea of shipping the font in both > formats, and I strongly like the idea of actually exercising _pfbtops_'s > code. Why do you like the idea? >> My first time attempt at using the bug-list email interface, so it >> probably >> won't work. > > It did not work out well. You need to be sure to GPG-sign the reply with > the key in your Savannah profile, and anything you put below the "savane" > line that the reply interface says **has** to be there, it will discard > from your message. > > I learned these things the hard way. Second time was better, made it to the list, but mangled the pdf attachment, this, the third attempt, got to be the charm. :-) _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?67207> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
