On 2020/03/05 23:06, Marc Espie wrote:
> > Can we do this?
> >
> > Index: bsd.port.mk
> > ===================================================================
> > RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> > retrieving revision 1.1520
> > diff -u -p -r1.1520 bsd.port.mk
> > --- bsd.port.mk 26 Feb 2020 15:34:48 -0000 1.1520
> > +++ bsd.port.mk 5 Mar 2020 21:29:25 -0000
> > @@ -1727,11 +1727,7 @@ _UNLOCK = echo "Unlocking $$lock from $@
> > _LOCK = ${LOCK_CMD} ${LOCKDIR_MODE} ${LOCKDIR}/$$lock.lock ${BUILD_PKGPATH}
> > _UNLOCK = ${UNLOCK_CMD} ${LOCKDIR}/$$lock.lock
> > . endif
> > -. if ${SEPARATE_BUILD:L:Mflavored}
> > _LOCKNAME = ${FULLPKGNAME}
> > -. else
> > -_LOCKNAME = ${PKGNAME}
> > -. endif
> >
> > . for _i in ${_LOCKNAME}
> > . if empty(_LOCKS_HELD:M${_i})
>
> The lock name change for SEPARATE_BUILD was an experiment for manual build,
> it can definitely go away.
Ignoring DPB's own locking - would you be OK with me changing this to
use FULLPKGNAME i.e. the diff above? or do you want to keep it using
PKGNAME? (Even if it's just for manual builds it's still helpful, if I'm
updating something like vim I can then run builds for all flavours at
once).
> > Mostly asking because the time for a full build has increased by about
> > a third in the last 3 months(!) and it would be helpful to be able to
> > build some of these flavoured ports in parallel (especially thinking
> > of chromium and electron here). Obviously that would need something
> > in DPB as well but there's no point looking at that if bsd.port.mk
> > won't allow them to run together.
>
> It's mostly impossible to do, the locks aren't designed that way.
>
> DPB would have to compute all kinds of information about which flavors
> correspond to which packages and everything... you would end up not
> being able to start anything before the full scan was done (which is THE
> main reason I started writing dpb, remember).
Oh yes, that makes sense.
> I told robert a while back I thought the electron/chromium organization
> was flawed.
>
> This shouldn't be a flavor, you should have two distinct paths that
> reach out and pull the same paths.
>
> It's definitely doable, and way less work than breaking apart dpb and
> trying to put it back together.
yep.
> I'm not sure we have other flavored ports in a similar situation (taking
> a lot of time to build like that).
>
> I know that some errors in flavored ports will block other ports from
> building, and that's definitely a concern...
>
> I'm not quite sure what the solution to that might be.
chromium/electron is by far the biggest one building two flavours,
when math/mlpack had py2+3 flavours that was also in the top 30,
but that has now gone (and chromium takes 5x as long as that).
> As naddy suggested, being able to remove a fullpkgpath from dpb's radar
> entirely would help in some cases (like when a flavor combination changed
> and blocks an important dependency, which currently can't be fixed without
> stopping dpb and restarting manually)
>
