Date: Sun, 04 Feb 2024 22:05:02 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 276789] math/openblas: Update to 0.3.26 Message-ID: <bug-276789-7788-NFIWTVFxHm@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-276789-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-276789-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276789 --- Comment #5 from Artyom Davidov <ard_1@mail.ru> --- (In reply to Daniel Engberg from comment #4) Hello Daniel! I'm sorry, but I'm totally against a proposed approach. It doesn't really simplify port it and makes it harder to debug and maintai= n. First of all, combining several AVX options into a single global one makes = the port less flexible. There are several reasons why there are three AVX optio= ns provided by OpenBLAS developers and I don't see any reason why we should combine them into a single one by ourselves. The second one is that there is no reason why we should follow an Arch Linux approach, since the current math/openblas port structure is almost optimal = and provides clean and easy way to a build process. In fact what the current FreeBSD port do is it's setting up an OpenBLAS Makefile.rules standard variables according to PORTOPTIONS and running a generic OpenBLAS build pipeline after that. It doesn't directly set up any custom compiler options nor it interfere in = any other ways with the OpenBLAS build process - and it's the way the port shou= ld be done 'cause it allows to easily update it to a newer version and report = bugs to upstream if we'll encounter some of them. On the other hand I'm not sure why the port fetching several archives with = the source code files and uses a GH tag instead of release archive but may be Eijiro Shibusawa can shed some light on it. IMO what this port is really missing is an option to enable FreeBSD CPUTYPE= to OpenBLAS TARGET variable mapping. It's presence will allow a more granular control of the resulting optimizations especially during DYNAMIC_ARCH build= s. But it seems that it'll be easy to implement it. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-276789-7788-NFIWTVFxHm>