Hi I did some comparisons running sysinfo 5 times for each test with one complete restart of fs-uae in between. Here's what I got: 68040/040 sysinfo test, fs-uae compiled with clang, 13-CURRENT amd64 Dhrystone 72223, 69189, 75229, 75808, 76020 68040/040 sysinfo test, fs-uae compiled with gcc7 Dhrystone 92611, 92801, 92660, 92489, 90485 If there are no objections, I think we should switch over to compiling the port with gcc. NOTE: These tests were done on fs-uae 2.9.7 but I've confirmed similar differences with 2.8.4.
While this is a desirable from an outcome (performance) perspective, it is also a slippery slope to many/most/any/all ports being built arbitrarily with a specific or particular compiler, for performance, or other reasons. Further, there is already a framework in place to allow users to choice to build with any compiler they want. Rather than an explicit and hardcoded switch to GCC (in this example), I might think the following 'could' be an option/alternative: - Add a GCC option - Not enabled by default - Create a fs-uae-gcc (sub) port, with that GCC option enabled by default. Though I am not advocating the above option, I think for certain *very* specific/compelling cases, it *might* be something valuable to provide users as a default.
As an end user, have to manage package built with custom options is a PITA. If you don't take care to lock the package it will get deleted and replaced by the default one at package update, just because the options are different. This happens to me all the time with boinc-client with linux option enabled... Creating fs-uae-gcc sounds like a good idea though. Can this be done using flavors? I'm not so familiar with flavors yet but if it allows for custom options without having to create yet another port then that sounds like a good idea.
(In reply to Johannes Lundberg from comment #2) Sure it is, but that's also the case for every/any port that provides any OPTION. flavoring for compiler/an OPTION may be possible, but I haven't seen many non-language-stack (like php/python) examples to confidently provide a categorical answer.
Created attachment 200111 [details] Make assignments optional to allow for slave ports Remove USE_GCC and make assignments optional to allow for slave ports
Any progress on this so we can get https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233957 committed?
(In reply to Johannes Lundberg from comment #5) > Any progress on this so we can get > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233957 committed? Since you have a src commit bit now, feel free to commit it yourself with Approved by: ports (tobik), tomse@oagd.net (maintainer timeout, > 2 months)
Review here https://reviews.freebsd.org/D20064
johalun has turned in his bit for safekeeping.
No longer needed without bug #233957.