[Bug 276789] math/openblas: Update to 0.3.26
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 276789] math/openblas: Update to 0.3.26"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 04 Feb 2024 22:05:02 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276789 --- 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 maintain. 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 options 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 should 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 builds. But it seems that it'll be easy to implement it. -- You are receiving this mail because: You are the assignee for the bug.