On Thu, Mar 05, 2020 at 09:43:24PM +0000, Stuart Henderson wrote:
> We only use SEPARATE_BUILD=(Yes|No) these days, so this conditional
> isn't needed. But also, it seems like it was the wrong way round anyway?
> I think the idea of =flavored was to allow doing several builds from the
> same unpacked ports source, *but* the lock in that case was to cope with
> cases where sometimes things were written in the source dir rather than
> the work dir...so shouldn't the lock in that case have prevented two
> different-flavoured builds of the same SEPARATE_BUILD=flavored port from
> being done at once (i.e. should have been a PKGNAME lock for =flavored
> and a FULLPKGNAME lock for !flavored)?
>
> 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.
> 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).
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.
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.
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)
