#48184: [NEW] kf5-attica -------------------------+-------------------------------- Reporter: mk@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kf5-attica | -------------------------+-------------------------------- Comment (by mk@…): Thanks to feedback on dev-ML I could come up with an improved Portfile, which makes use of the new port group 'kf5'. -- Ticket URL: <https://trac.macports.org/ticket/48184#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X

#48184: [NEW] kf5-attica -------------------------+---------------------- Reporter: mk@… | Owner: mk@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kf5-attica | -------------------------+---------------------- Comment (by rjvbertin@…): You're probably better acquainted with building KF5 most all on here, but be careful that you don't end up duplicating lots of stuff. IF KF5 has a single versioning scheme for all or at least a good part of its frameworks that gets built through the kdesrc-or-what's-it-called script, I'd strongly advise to use your KDE/CI experience to coerce that script into a portfile. There *must* be a KF5 "subset" (a collection of frameworks) that one will have to install anyway in order to run a productivity application (KDevelop, KDE PIM, digiKam, ...). Introducting countless individual ports one by one that each provide a single framework that is of no use in itself seems like an approach that won't attract a lot of interest. A single port that builds an ensemble that makes sense (= that you can do something with) seems a lot more interesting as a target to collaborate on. That approach should also allow you to move stuff (name, description, version, probably a bunch of the configure args) out of the kf5 portgroup because they relate only to building KF5 and not building dependents (say, digiKam). Alternatively, you'd probably want to rename the portgroup to something that makes it clear it's an internal include file, not something to be used by any other port that provides an application that depends on KF5. -- Ticket URL: <https://trac.macports.org/ticket/48184#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X

#48184: [NEW] kf5-attica -------------------------+---------------------- Reporter: mk@… | Owner: mk@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kf5-attica | -------------------------+---------------------- Comment (by rjvbertin@…): Replying to [comment:4 mk@…]:

Alternatively I could create two port groups one called {{{kf5-framework}}} and the other {{{kf5-project}}}. I guess that needs discussion on the dev-ML...

`kf5-internal` and `kf5`? Not that the Qt portgroups don't have a variable that indicates whether the port itself is building (= they do) ... but I think a single kf5 portgroup would become more complex than necessary /good-for-it that way.

...

... I'd strongly advise to use your KDE/CI experience to coerce that

script into a portfile.

For testing I have half-automatically created about 20 port files now.

Of course I will come up with some helper scripts to create the required portfiles. See [https://github.com/haraldF/homebrew-kf5 Haralf Fernengel's HB github repo]!. There's always the possibility to generate a slew of subports programmatically, but that would make sense only if all those subports have the same dependencies.

Yes, there is, but the subset is built up of all those little KF5-ports. Every project has its own subset depending on its specific requirements.

That the subset is built up out of a trazillion KF5 morsels isn't an issue as long as there's a script (like I understand there is) that takes care of building them as if they were a whole. That each KF5 "client" application depends on its own individual subset isn't an issue either. Declaring a dependency on `port:kf5` doesn't mean you have to link in all those frameworks (just like depending on `port:qt5-mac` doesn't mean you link with all Qt components. Again, suppose it turns out that you end up installing just about all KF5 frameworks when you actually want to install systemsettings5, kate, konsole, KDevelop, KDE PIM, kdesvn and digiKam (just to name the ones I use regularly). In that case, isn't it much easier to have only a single port they need to depend on? There *is* a kdesrc script that supposedly takes care of the whole build process, no?

Well, in the end I could create meta-ports which might perhaps build the individual tiers of the KF5 frameworks.

Hmmm, and in true hipster fashion you'd be doing that at a table in the Restaurant at the End of the Universe? ;) -- Ticket URL: <https://trac.macports.org/ticket/48184#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X

#48184: [NEW] kf5-attica -------------------------+------------------ Reporter: mk@… | Owner: mk@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: kf5-attica | -------------------------+------------------ Comment (by mk@…): Replying to [comment:5 rjvbertin@…]:

`kf5-internal` and `kf5`?

Or {{{kf5-frameworks}}} and {{{kf5}}}?

a single kf5 portgroup would become more complex than necessary/good- for-it that way.

Yep.

There's always the possibility to generate a slew of subports programmatically, but that would make sense only if all those subports have the same dependencies.

If I - perhaps - create a script for this job it would do everything programmatically. I believe that Harald's scripts also do that using KDE's dependency information.

Declaring a dependency on `port:kf5` doesn't mean you have to link in all those frameworks (just like depending on `port:qt5-mac` doesn't mean you link with all Qt components.

Good point. But still, if you do it on a fine-granular level you only include a few {{{kf5}}} ports instead of the whole set of 60 frameworks.

Again, suppose it turns out that you end up installing just about all KF5 frameworks when you actually want to install systemsettings5, kate, konsole, KDevelop, KDE PIM, kdesvn and digiKam (just to name the ones I use regularly). In that case, isn't it much easier to have only a single port they need to depend on?

I agree there. Let's see how it works out, if I find more time to deal with this submission... It's not top prio for me ATM, as you know. :)

There *is* a kdesrc script that supposedly takes care of the whole build process, no?

Yes, but I am not using that.

Hmmm, and in true hipster fashion you'd be doing that at a table in the Restaurant at the End of the Universe? ;)

At table No. 42, of course. ;) -- Ticket URL: <https://trac.macports.org/ticket/48184#comment:7> MacPorts <https://www.macports.org/> Ports system for OS X

#48184: [NEW] kf5-attica -------------------------+------------------ Reporter: mk@… | Owner: mk@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: kf5-attica | -------------------------+------------------ Comment (by rjvbertin@…): Are you still interested in a dedicated qt5-kde port (presumably with its own PortGroup file just so we can be our own control freaks)? -- Ticket URL: <https://trac.macports.org/ticket/48184#comment:9> MacPorts <https://www.macports.org/> Ports system for OS X

#48184: [NEW] kf5-attica -------------------------+------------------ Reporter: mk@… | Owner: mk@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: kf5-attica | -------------------------+------------------ Comment (by rjvbertin@…): Well, that's the role of the PortGroup file, ensuring that a Qt5 dependent port can accept either flavour of the Qt5 ports. Shouldn't take me very long, but I have a few other real-life things on my plate that have to get priority (in addition to a "survive the current heatwave" project :-/) -- Ticket URL: <https://trac.macports.org/ticket/48184#comment:11> MacPorts <https://www.macports.org/> Ports system for OS X

#48184: [NEW] kf5-attica -------------------------+------------------ Reporter: mk@… | Owner: mk@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: kf5-attica | -------------------------+------------------ Comment (by mk@…): I have all 61 KF5 frameworks building here locally by now, so this is only an example for the rest of it, including porting aids. The only complication is that I need a specific version of the phonon port, see #46552, where the {{{post-patch}}} phase is commented out. -- Ticket URL: <https://trac.macports.org/ticket/48184#comment:13> MacPorts <https://www.macports.org/> Ports system for OS X

#48184: [NEW] kf5-attica -------------------------+------------------ Reporter: mk@… | Owner: mk@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: kf5-attica | -------------------------+------------------ Comment (by mk@…): I am close to give up on KF5 for now, as I have no clue why it suddenly fails to install the files in the correct OSX'ish location... :-( -- Ticket URL: <https://trac.macports.org/ticket/48184#comment:15> MacPorts <https://www.macports.org/> Ports system for OS X

#48184: [NEW] kf5-attica -------------------------+------------------ Reporter: mk@… | Owner: mk@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: kf5-attica | -------------------------+------------------ Comment (by mk@…): Hi Kurt, Replying to [comment:17 khindenburg@…]:

MK, have you uploaded any of your KF5 ports anywhere? I don't see them in https://svn.macports.org/repository/macports/users/mk

yes, but as mentioned in my [https://mail.kde.org/pipermail/kde- mac/2015-September/003872.html KDE-MAC post on KF5 on OSX] the [https://quickgit.kde.org/?p=macports- kde.git&a=commit&h=2c8d3f2fd93d3f5a002645f54956265c3398ca58 repo with the portfiles] resides on KDE's infrastructure. Greets, Marko -- Ticket URL: <https://trac.macports.org/ticket/48184#comment:18> MacPorts <https://www.macports.org/> Ports system for OS X