[NEW] kf5-attica

[mkae (Marko Käning)]

Now that a concurrent qt5-mac is in place I wanted to introduce the first KF5 port, but although kf5-attica installs, it has a problem with file system violation:

$ sudo port install
--->  Computing dependencies for kf5-attica
--->  Fetching archive for kf5-attica
--->  Attempting to fetch kf5-attica-5.11.0_0.darwin_13.noarch.tbz2 from http://nue.de.packages.macports.org/macports/packages/kf5-attica
--->  Attempting to fetch kf5-attica-5.11.0_0.darwin_13.noarch.tbz2 from http://lil.fr.packages.macports.org/kf5-attica
--->  Attempting to fetch kf5-attica-5.11.0_0.darwin_13.noarch.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/kf5-attica
--->  Staging kf5-attica into destroot
Warning: violation by /opt/local/mkspecs
Warning: kf5-attica violates the layout of the ports-filesystems!
Warning: Please fix or indicate this misbehavior (if it is intended), it will be an error in future releases!
--->  Installing kf5-attica @5.11.0_0
--->  Activating kf5-attica @5.11.0_0
--->  Cleaning kf5-attica
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.

Any idea what could be done to fix this problem?

[mkae (Marko Käning)]

Thanks to feedback on dev-ML I could come up with an improved Portfile, which makes use of the new port group 'kf5'.

[RJVB (René Bertin)]

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.

[mkae (Marko Käning)]

Replying to 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.

I am still in the process of setting up all those KF5 port files here. (I am in tier 3 by now.)

Believe me, I don't want to duplicate anything unnecessarily, which is why I created the kf5 port group.

Yes, at the moment this port group is only taking care of frameworks, but I want to allow also normal projects depending on some variables set before the PortGroup command (a la ${KF5_PROJECT} - which will change meaning soon).

... 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 ​Haralf Fernengel's HB github repo!.

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, ...).

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.

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.

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

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.

See above, the current state of the portfile and port group are only transitional and things will change!

[RJVB (René Bertin)]

Replying to 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 ​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? ;)

[mf2k (Frank Schima)]

There is no need to use a keyword for a submission ticket.

[mkae (Marko Käning)]

Replying to 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. ;)

[mkae (Marko Käning)]

My Portfile-generating bash-script is able to build up to tier 3. I am stopped at kf5-knotifications, as phonon-qt5 ​is still making trouble due to current (concurrent) qt5-mac...

[RJVB (René Bertin)]

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)?

[mkae (Marko Käning)]

Yes, absolutely!

I will formulate the kf5-framework and kf5 port groups in such a way, that they accept qt5-kde as well as qt5-mac, since I hope that one day the latter will also be capable to deal with what your version can do. :)

[RJVB (René Bertin)]

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 :-/)

[mkae (Marko Käning)]

Replying to rjvbertin@…:

Well, that's the role of the PortGroup file, ensuring that a Qt5 dependent port can accept either flavour of the Qt5 ports.

Yep.

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 :-/)

Dito and dito - here. :-/

[mkae (Marko Käning)]

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.

[mkae (Marko Käning)]

Current status of kf5 port group making use of specific variable settings to define what the project's type is.

[mkae (Marko Käning)]

The corresponding short Portfile for kf5-attica.

[mkae (Marko Käning)]

Ooops, had to update the two files once more, since I uploaded old files previously.

[mkae (Marko Käning)]

kjs' Portfile as an example for a porting aid.

[mkae (Marko Käning)]

Don't know why (suddenly) kf5-kdoctools installs its files catalog files in the Linuxy location instead of below /Library/Application Support/ as instructed in kf5-1.0 port group

[mkae (Marko Käning)]

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... :-(

[kurthindenburg (Kurt Hindenburg)]

Cc Me!

[kurthindenburg (Kurt Hindenburg)]

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

I currently have most (5.14) of the lower tiers installed via kdesrc-build.

[mkae (Marko Käning)]

Hi Kurt,

Replying to 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 ​KDE-MAC post on KF5 on OSX the ​repo with the portfiles resides on KDE's infrastructure.

Greets, Marko

[mkae (Marko Käning)]

I've stopped working on this (for now), as René is in the process of setting up a more general approach (including his XDG patch) to this ​in his macstrop repository.