#52318: libproxy KDE variant modifications -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: haspatch | Port: libproxy -------------------------+-------------------------------- The current port:libproxy's +KDE variant doesn't actually have any effect. The KDE module is built even without it. In itself that's fine because that module now has a pure runtime dependency on KDE, but that also means that the +KDE variant no longer needs to pull in hard KDE dependencies. The attached patch is a proposition. Since it's entirely unclear what use the KDE module has I have decided not to make it depend on any KDE or Qt port because a priori it won't even be used if no KDE software asks for it. And I have yet to find evidence that this is the case. There are no repercussions on the reproducible build principle. I did include one additional change: with KDE being based on Qt/Cocoa (= using native APIs) it seems reasonable to let libproxy use native APIs too. Is there a reason why this isn't the default, BTW, why libproxy isn't always built against native APIs which allow it to actually detect the system proxy correctly? -- Ticket URL: <https://trac.macports.org/ticket/52318> MacPorts <https://www.macports.org/> Ports system for macOS