Date: Thu, 15 Jul 2021 17:21:54 +0000 From: Alexey Dokuchaev <danfe@freebsd.org> To: Piotr Kubaj <pkubaj@anongoth.pl> Cc: Guido Falsi <madpilot@freebsd.org>, ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org Subject: Re: git: dc9bf7d64926 - main - net/asterisk*: Add aarch64 support Message-ID: <YPBusr8yRq3Lk0xV@FreeBSD.org> In-Reply-To: <YPBrLBa%2BrGGt/aoH@KGPE-D16> References: <202107141033.16EAX60T044972@gitrepo.freebsd.org> <YO%2BYP1TDjq6MruvC@FreeBSD.org> <81bc6b76-7b74-9990-d7dc-54ca14b0ee4f@FreeBSD.org> <YPBpeWTJvGwMv1FL@FreeBSD.org> <YPBrLBa%2BrGGt/aoH@KGPE-D16>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 15, 2021 at 07:06:52PM +0200, Piotr Kubaj wrote: > On 21-07-15 16:59:37, Alexey Dokuchaev wrote: > > ... > > Right. I think it's generally bad idea to prematurely restrict software > > to certain arches unless it's clearly arch-specific (e.g. comes only in > > binary precompiled form or uses asm code). New arches appear frequently > > (e.g. powerpc64le, riscv64) and some go away as well (ia64, sparc64), it > > just does not look feasible to maintain those ONLY_FOR_ARCHS lists so > > they'd always reflect the reality. > > This is the reason I prefer NOT_FOR_ARCHS -- it doesn't require any > intervention after adding new architectures. NOT_FOR_ARCHS is slightly better (due to its limited scope), but what I've said above about still applies: this knob is for inherently arch-specific software, and should not be used instead of BROKEN_$arch for arch-agnostic programs which do not build on $arch for some other reason: that is, they should, but they don't, while NOT_FOR_ARCHS means they really cannot be before their code gets changed to be even theoretically portable first. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YPBusr8yRq3Lk0xV>