Re: git: 53c1ad8c4add - main - bsd.port.mk: run pkg-create with MAKE_JOB_NUMBER threads

On Wed, Mar 4, 2026 at 2:16 PM Vladimir Druzenko <vvd@freebsd.org> wrote:
>
> 04.03.2026 21:53, Daniel Engberg пишет:
> > On 2026-03-04 18:57, Adam Weinberger wrote:
> >> On Wed, Mar 4, 2026 at 9:40 AM Siva Mahadevan <siva@freebsd.org> wrote:
> >>> The branch main has been updated by siva:
> >>>
> >>> URL:
> >>> https://cgit.FreeBSD.org/ports/commit/?id=53c1ad8c4add9656b4ee3e0d1a1c1b643d617f84
> >>>
> >>> commit 53c1ad8c4add9656b4ee3e0d1a1c1b643d617f84
> >>> Author:     Siva Mahadevan <siva@FreeBSD.org>
> >>> AuthorDate: 2026-03-04 14:39:04 +0000
> >>> Commit:     Siva Mahadevan <siva@FreeBSD.org>
> >>> CommitDate: 2026-03-04 14:39:30 +0000
> >>>
> >>>      bsd.port.mk: run pkg-create with MAKE_JOB_NUMBER threads
> >>>
> >>>      Following the same as https://reviews.freebsd.org/D53053
> >>>      in the src tree.
> >>>
> >>>      Reviewed by:    portmgr (bapt)
> >>>      Approved by:    lwhsu (mentor, implicitly)
> >>>      Differential Revision: https://reviews.freebsd.org/D55232
> >> Thank you for this! The difference is incredible. On the aging
> >> E3-1270v2 in my rented box, it brought packaging llvm from 20 minutes
> >> down to 10.
> >
> > There are some caveats to take into considering though which should've
> > been documented.
> > https://github.com/facebook/zstd/issues/2079
> > For xz this breaks reproducible builds,
> > https://www.mail-archive.com/xz-devel@tukaani.org/msg00375.html
> >
> > Best regards,
> > Daniel
>
> And the compression ratio is also reduced.

Thanks, Daniel and Vladimir, I'm really glad to have that information.

It also struck me as a little odd to use MAKE_JOBS_NUMBER explicitly
in the pkg-create(8) command. MAKE_JOBS_UNSAFE is generally for when a
Makefile doesn't handle parallelism correctly, and generic user me
would be surprised to find that packaging is single-threaded on some
ports but not others.

I tried to address that and the above points by adding a simple patch
to the above phabric review that introduces a new variable to be used
for this purpose. That way it's possible for people to go back to
single-threaded packaging if they desire, while not limiting build
parallelism in the process.

If either of you have thoughts on that approach in the context of the
concerns you brought up, I'd really love to hear them.


-- 
Adam Weinberger
adamw@adamw.org // adamw@FreeBSD.org