[KDE4]: move headerfiles to a dedicated TLD and other housekeeping

[RJVB (René Bertin)]

As already mentioned on macports-dev, it turns out to be preferable to store the KDE4 headerfiles under a prefix directory where there is less chance they'll clash with KF5 headerfiles. Otherwise, conflicts will arise when building KF5 frameworks or applications (I've already witnessed such conflicts that were resolved by the attached fix, which is why I label this ticket a defect).

The attached patchfile accomplishes that. It defines the new path, ${prefix}/include/KDE4 in the KDE4 PortGroup, and applies it the kdelibs4 Portfile. For the (presumable vast) majority of dependent ports this is all that is required, as kdelibs4 installs cmake scripts that will set the new include path. There are a few exceptions like Phonon and Attica, but as far as I can tell now they will not lead to clashes so their headers can remain where they are now.

I was afraid that all dependent ports might require a revbump because of this, but it turns out that that is not strictly required. The current patch does not cause binary incompatibilities, and the change to the header search path in the cmake scripts does not cause errors finding headers in their old locations. That change only ensures that the headers can be found in their new location. (Ex: I could rebuild port:kdenlive without having to rebuild port:kde4-runtime first, and port:nepomuk-widgets without having to rebuild port:nepomuk-core first.)

[mkae (Marko Käning)]

Cc Me!

[RJVB (René Bertin)]

Here's a somewhat refreshed version that does a few more useful things in addition to moving the KDE4 headerfiles "out of the way":

• use a specific MacPorts CMAKE_BUILD_TYPE, forcing CMake to take CFLAGS, LDFLAGS etc. settings from the environment into account
• adds a post-activate step which rebuilds the global sycoca4 cache
• adds a few missing dependencies to kdelibs4
• fixes a number of hard-coded paths to point to ${prefix}
• adds a wrapper so that kdeinit4 can finally be auto-started

The afsctool post-build step is there mainly because I was lazy to hand-edit the patchfile to get rid of it; I reckon it could be a useful touch for other port developers who like me keep the ${workpath} around after installing.

(Marko: maybe you could "and other housekeeping" to the ticket title, or something of the sort?)

[mkae (Marko Käning)]

Is the global sycoca5-cache root's?

[RJVB (René Bertin)]

Replying to mk@…:

Is the global sycoca5-cache root's?

sycoca4 in this case ;)

I suppose it is, though more often than not (kde)su'd applications will probably be using the user's cache instead. I suppose the global cache is also used in cases where there is no user cache (yet). I'm not really convinced it's a crucial thing, but I saw no reason not to add the operation given that this global cache is generated somewhere in a place under ${prefix} where it shouldn't bite anything.

[mkae (Marko Käning)]

Replying to rjvbertin@…:

sycoca4 in this case ;)

Oh, yes. :)

I suppose the global cache is also used in cases where there is no user cache (yet).

I wasn't even aware that there is a global cache. I thought everything would be kept cached on a per-user-basis...

but I saw no reason not to add the operation given that this global cache is generated somewhere in a place under ${prefix} where it shouldn't bite anything.

Cool that you noticed this! :-D

[mkae (Marko Käning)]

Is the missing letter 'a' in line 63 of ​the first patch deliberate?

Is this ticket related to #52689?

[RJVB (René Bertin)]

No, that was a typo or "alignment accident". Thanks for noticing.

Yes, there's an indirect relationship with that other ticket in that my changes to the KDE4 PortGroup provide part of the necessary "framework" to install KDE4 in a way that KF5 can be co-installed. It is not really related to the exact problem reported, which can also be addressed on its own.

However, if we start fixing things that occur because Qt5 is installed we can just as well handle everything related to Qt5's presence, including the potential presence of KF5.

Let me repeat that all changes I made to the KDE4 PortGroup have proven to be "transparent" for me in the sense that they did not require rebuilding all KDE4 ports I had installed. I did rebuild kde4libs, though, with the accompanying changes to that port.

[mkae (Marko Käning)]

Can you file updated patches for review?

[RJVB (René Bertin)]

Done.

[mkae (Marko Käning)]

@RJVB, what's the status here?

[RJVB (René Bertin)]

The main point has been addressed, possibly these remain:

• adds a few missing dependencies to kdelibs4
• fixes a number of hard-coded paths to point to ${prefix}
• adds a wrapper so that kdeinit4 can finally be auto-started