Mark Linimon wrote:
>> BTW, I apologize for this is not at all a portupgrade issue, but an issue
>> of the ports system.
>
> It is an issue with individual ports -- actually not the "port" (e.g.
> Makefile framework, pkg-*) but the individual applications (IIUC).
>
>> Well, at least the ports system itself should not be broken able to work
>> with this. With larger ports I manage to reduce build times by 40% with
>> distcc and a second machine. As far as I see it the number of ports
>> breaking is rather low.
>
> Please feel free to suggest a framework (complete with regression test
> framework) where the infrastructure code can "learn" which ports are safe.
> I think it's going to be a harder problem than you think it is. Note that
> "appears to work" and "can be shown to work under arbitrary build
> circumstances for all users" are IMHO going to be two very different
> classes of problem -- and the latter will need to be solved before it
> can be used on the package-building cluster.
I do not expect anyone to check weather ports support it or not. I can track
this for myself in my make.conf, but the problem for me is that the ports
framework itself doesn't support it. I am able to work around the broken
install target with this:
.if defined(THREADS)
.if !make(*install)
.MAKEFLAGS: -j ${THREADS}
.else
USE_SUBMAKE= yes
MAKE_ARGS:= -j ${THREADS}
.NOTPARALLEL::
.endif
.endif
But 'make -j N config' is also broken (the config dialogue cannot see the size
of the terminal and does not receive key events) and I did not find a
workaround for this so far.
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
