Created attachment 542226 [details] ebuild This ebuild builds qcachegrind, a Qt frontend for Cachegrind, which doesn't have dependencies to kde libs (as opposed to kcachegrind).
> RESTRICT+=" mirror" This package is prohibited from being saved from the mirrors? Why? It looks as if it's just a subdirectory of kcachegrind which has no such RESTRICT.
Created attachment 542228 [details] new ebuild (removed RESTRICT, src_compile and made for loop variable local) (In reply to Brian Evans from comment #1) > > RESTRICT+=" mirror" > > This package is prohibited from being saved from the mirrors? Why? It looks > as if it's just a subdirectory of kcachegrind which has no such RESTRICT. My bad. I had copied to much from kde5.eclass (the RESTRICT was for the unstable mirror).
FWIW, this ebuild works fine for me.
*** Bug 686070 has been marked as a duplicate of this bug. ***
Since we do have kcachegrind already, why would you avoid a few KF5 libs? From the upstream README: >This directory just contains _example_ code for using KCachegrind's >libcore/libviews in Qt-only apps, such as IDEs. >... >For demonstration purpose, qcachegrind can be build without KDE libs >at all, using just qmake with the example qcachegrind.pro file. >For this, run "qmake; make". ^ I doubt this is really something upstream wants to be officially support.
(In reply to Andreas Sturmlechner from comment #5) > Since we do have kcachegrind already, why would you avoid a few KF5 libs? > > From the upstream README: > >This directory just contains _example_ code for using KCachegrind's > >libcore/libviews in Qt-only apps, such as IDEs. > >... > >For demonstration purpose, qcachegrind can be build without KDE libs > >at all, using just qmake with the example qcachegrind.pro file. > >For this, run "qmake; make". > > ^ I doubt this is really something upstream wants to be officially support. On my system it's 26 additional packages that would be emerged for kcachegrind. That's more than just a "few" libs. I'd just like to avoid unnecessary packages on my system and I think I'm not alone with that desire. But I see your point that the upstream support is an issue. I wasn't aware that it was just example code. I mainly created the issue to share the ebuild, because I thought it might be of use to others. But if it's something that cannot be maintained so be it.
(In reply to Markus Fischer from comment #6) > On my system it's 26 additional packages that would be emerged for > kcachegrind. That's more than just a "few" libs. I'd just like to avoid > unnecessary packages on my system and I think I'm not alone with that desire. The functionality provided by those libs would otherwise have to be recreated by more code in the application itself - and let's not forget that those 12 or so Frameworks packages back in the day were part of one monolithic kdelibs package, maybe giving the impression of 'less deps' but in fact being much, much bigger. There's still room for improvement, mainly kde-frameworks/kio pulling in lots of other Frameworks, but that's one of the things being worked on for KF6. For now, this will be a WONTFIX as qcachegrind is no real upstream product.
