Bug 233956 - emulators/fs-uae: Allow overrides for new fs-uae-devel port
Summary: emulators/fs-uae: Allow overrides for new fs-uae-devel port
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Johannes Lundberg
URL:
Keywords: needs-qa
Depends on:
Blocks: 233957
  Show dependency treegraph
 
Reported: 2018-12-12 12:25 UTC by Johannes Lundberg
Modified: 2019-05-21 21:36 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (tomse)


Attachments
Make assignments optional to allow for slave ports (1.23 KB, patch)
2018-12-14 10:38 UTC, Johannes Lundberg
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Lundberg 2018-12-12 12:25:33 UTC
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.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2018-12-14 05:50:29 UTC
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.
Comment 2 Johannes Lundberg 2018-12-14 08:11:56 UTC
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.
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2018-12-14 09:18:37 UTC
(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.
Comment 4 Johannes Lundberg 2018-12-14 10:38:09 UTC
Created attachment 200111 [details]
Make assignments optional to allow for slave ports

Remove USE_GCC and make assignments optional to allow for slave ports
Comment 5 Johannes Lundberg freebsd_committer 2019-02-18 08:22:26 UTC
Any progress on this so we can get https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233957 committed?
Comment 6 Tobias Kortkamp freebsd_committer 2019-02-23 04:42:59 UTC
(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)
Comment 7 Johannes Lundberg freebsd_committer 2019-05-21 21:36:11 UTC
Review here https://reviews.freebsd.org/D20064