[MacPorts] #49595: [KDE4]: move headerfiles to a dedicated TLD
#49595: [KDE4]: move headerfiles to a dedicated TLD -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: haspatch | Port: kdelibs4 -------------------------+-------------------------------- 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.) -- Ticket URL: <https://trac.macports.org/ticket/49595> MacPorts <https://www.macports.org/> Ports system for OS X
#49595: [KDE4]: move headerfiles to a dedicated TLD --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by rjvbertin@…): 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?) -- Ticket URL: <https://trac.macports.org/ticket/49595#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X
#49595: [KDE4]: move headerfiles to a dedicated TLD --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by mk@…): Is the global sycoca5-cache root's? -- Ticket URL: <https://trac.macports.org/ticket/49595#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X
#49595: [KDE4]: move headerfiles to a dedicated TLD and other housekeeping --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- -- Ticket URL: <https://trac.macports.org/ticket/49595#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X
#49595: [KDE4]: move headerfiles to a dedicated TLD and other housekeeping --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by rjvbertin@…): Replying to [comment:3 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. -- Ticket URL: <https://trac.macports.org/ticket/49595#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X
#49595: [KDE4]: move headerfiles to a dedicated TLD and other housekeeping --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by mk@…): Replying to [comment:5 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 -- Ticket URL: <https://trac.macports.org/ticket/49595#comment:6> MacPorts <https://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts