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.