Re: disable parallel make for "fake"

On Mon, Mar 30, 2026 at 12:04:37PM +0100, Stuart Henderson wrote: > On 2026/03/30 12:25, Theo Buehler wrote: > > On Mon, Mar 30, 2026 at 11:09:50AM +0100, Stuart Henderson wrote: > > > Some ports are happy to _build_ in parallel, but fail during "make > > > fake". For example, vim and php. > > > > > > We used to have a separate PARALLEL_INSTALL variable controlling > > > whether parallel flags were passed through there, added in r1.920, > > > removed in r1.1510. > > > > > > I'm not convinced that parallel fake is enough of a win to be worth > > > restricting the number of ports that can use parallel build so I'd like > > > to remove it. (Apart from rare semi-broken ports which do a chunk of > > > compilation during "make fake", it's mostly going to be filesystem > > > access which doesn't parallelize brilliantly on OpenBSD at present > > > anyway). > > > > One of the ports where this will really hurt is x1//qt5/qtbase which > > rebuilds itself in its entirety during fake. > > Oof. > > > I don't know how many rust ports with DPB_PROPERTIES=parallel there are > > but if any of them sets MODCARGO_INSTALL_TARGET_PATHS, it will likely > > build a non-trivial amount of stuff as well. > > Perhaps it does want an easier way to select on/off than adding to > FAKE_FLAGS then. (I don't know what the default should be). > > re rust: lang/deno, mail/stalwart, www/chromium, www/iridium set > DPB_PROPERTIES. (ungoogled-chromium doesn't currently have rust parts). > stalwart is the only one setting MODCARGO_INSTALL_TARGET_PATHS. > However, in general rust ports do seem like they might be a good > candidate for parallel, and MODCARGO_INSTALL_TARGET_PATHS is fairly > common. > > > So while I'm ok with this in principle, I think this needs to run > > through a bulk or two to see if it doesn't add a significant amount of > > build time. > > Makes sense, I think I'll try to find some time later during lock to > do some testing. > > You could always disable by default and add it by hand in the corresponding ports. After all, both PARALLEL_MAKE_FLAGS and ALL_FAKE_FLAGS are user-visible variables, with nothing preventing people from handling them manually. If there's just a small number of ports, it's simpler than re-adding another flag.