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})
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.
