Created attachment 243536 [details] patch
Why adding an OPTION instead of supporting CPUTYPE?
(In reply to Benjamin Takacs from comment #1) > Why adding an OPTION instead of supporting CPUTYPE? Because: * this project defined an option based on "native" vs. "none" choice, which makes sense * CPUTYPE is functionally equivalent to the NATIVE option in this case * CPUTYPE would require more lines in the Makefile in this case * IMO NATIVE option is more intuitive Yuri
Please don't do this, it (native) breaks in various ways and is non functional on anything non amd64. As Benjamin pointed out use CPUFLAGS and you can pass that variable to CMAKE if needed for whatever reason.
(In reply to Daniel Engberg from comment #3) ...err, CPUFLAGS --> CPUTYPE of course
Wouldn't it be better to just specify CFLAGS/CXXFLAGS/FFLAGS outside the individual ports? Adding CXXFLAGS+=-march=native to /etc/make.conf on systems where analyses are run will optimize the build of all ports that respect the env (which should in theory be all of them, but we know better).
Yes, but that would be redundant to defining CPUTYPE per port ;-)
(In reply to Daniel Engberg from comment #6) Thanks Daniel, I agree - NATIVE option is a bad idea. I'll update the patch. Yuri
Created attachment 244037 [details] patch This patch passes CPUTYPE to cmake when it is set.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=f38473fec0a852349f186e1d28358fc2ce5636de commit f38473fec0a852349f186e1d28358fc2ce5636de Author: Jason W. Bacon <jwb@FreeBSD.org> AuthorDate: 2023-08-12 14:38:47 +0000 Commit: Jason W. Bacon <jwb@FreeBSD.org> CommitDate: 2023-08-12 14:38:47 +0000 biology/bifrost: Control -march via CPUTYPE make variable Also disable hard-coded -O3 in cmake to respect user env PR: 272651 Reported by: yuri Reviewed by: nimaje+fbz@bureaucracy.de, dizzy biology/bifrost/Makefile | 5 ++++- biology/bifrost/files/patch-CMakeLists.txt | 17 ++++++++--------- 2 files changed, 12 insertions(+), 10 deletions(-)
Thanks for the input!