Date: Thu, 2 Apr 2026 16:19:34 +0300 From: Eygene Ryabinkin <rea@freebsd.org> To: Gleb Popov <arrowd@freebsd.org> Cc: Yuri Victorovich <yuri@freebsd.org>, ports-committers <ports-committers@freebsd.org>, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org Subject: Re: git: 097b8e780932 - main - misc/ollama: Fix package on non-x86 architectures Message-ID: <wyvdnktd2nwj4zx4vvwmectw3xkj5l4hapkycjoskhrjpyghzp@edrzpm2ul5tx> In-Reply-To: <CALH631k7WN7pVe2aE6PzPQa0YxPMbgPQagvqO%2Bpx6VGcTBRZEw@mail.gmail.com> References: <69ce1085.20cac.772d7539@gitrepo.freebsd.org> <CALH631mHaMRmvmugX90u-ep5D73=QqY0S_9MiZxwk8zX1M3VcQ@mail.gmail.com> <2995c1f6-79b2-4119-9168-09df9e24736a@freebsd.org> <CALH631k7WN7pVe2aE6PzPQa0YxPMbgPQagvqO%2Bpx6VGcTBRZEw@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
Good day.
Thu, Apr 02, 2026 at 11:20:49AM +0200, Gleb Popov wrote:
> On Thu, Apr 2, 2026, 09:44 Yuri Victorovich <yuri@freebsd.org> wrote:
> > On 4/2/26 00:12, Gleb Popov wrote:
> >
> >> Why not use canonical ${ARCH} ?
> >
> > Because ${ARCH} requires ".include <bsd.port.pre.mk>" which might hurt
> > options handling because ${ARCH} is used here to change option related
> > values.
>
> > The XARCH variable here is no strings attached, but ${ARCH} is not.
> >
>
> Not sure what including port.pre.mk breaks for you exactly,
Gleb, what bothers you in reality? The handling logic for OPTIONS
is rather non-trivial, so decoupling the parts of it (GPU_PLIST_FILES)
from the ARCH variable _can_ potentially be a good thing.
> but I'm sure the problem can be solved
Which one? The one that you're not sure about? First, I wanted to say
"then, if you're sure that the problem can be solved, perhaps you can produce
a patch?", but if you're not sure about the problem, then it makes no sense
to say that.
> in a canonical way, without resorting to != in the main Makefile.
I'd say that the "next worst thing" with != in the main Makefile
and XARCH will be to use
{{{
XARCH!= ${MAKE} -V ARCH -f bsd.port.pre.mk 2>/dev/null
}}}
to have XARCH to be set precisely to the value of ARCH (not relying
on the current 'uname -p' output in the main branch of bsd.port.mk
logics).
"Worst" here means that you won't be happy with this approach,
but in it XARCH and ARCH shall be consistent if ARCH handling
will be altered in the future.
Am I missing something?
--
Eygene Ryabinkin ,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?wyvdnktd2nwj4zx4vvwmectw3xkj5l4hapkycjoskhrjpyghzp>