Follow-up Comment #35, bug #67207 (group groff): At 2025-06-24T10:34:32-0400, Deri James wrote: > Follow-up Comment #34, bug #67207 (group groff): >> We use the "mv $@.tmp $@" technique in other places without >> provoking this issue, at any rate, so the foregoing is my guess. > > Almost there. mv $@.tmp $@ works great if $@ does not already exist > with read- only permissions, similarly copying download.in works great > if the mv has not already happened.
Acknowledged. > With 16 cores make -j would sometimes work (when the cp and > the mv finished before the chmod -R a=r hit). That's surprising to me. I don't think GNU make(1)--or any make(1)--tries to execute the individual lines of target rule scripts concurrently (only the targets-as-prerequisites--each one gets a "token" as POSIX Issue 8 puts it[1]), and moreover we usually serialize operations with the shell's `&&` operator in such rules. I could be wrong... And if you get failures sometimes with "-j 16" and sometimes not, odds are high that _something_ is racing! Please file a new ticket against "Build/Installation" if you narrow it down any. >> 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? Bugs lurk in untested code. > Second time was better, made it to the list, but mangled the pdf > attachment, this, the third attempt, got to be the charm. :-) I think it was! :D [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?67207> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
