https://bugs.kde.org/show_bug.cgi?id=388370
--- Comment #8 from Ralf Habacker <ralf.habac...@freenet.de> --- (In reply to Sven Brauch from comment #7) > Hm, we were not aware of Umbrello using KDevPlatform at the time where we > decided to merge the two repos. We were under the impression that nobody was > using it at all. Effectively, this means you depend on KDevelop now instead > of KDevPlatform, which I can see how it is a bit unfortunate (but not the > end of the world). Then the dependency needs to be 'kdevelop' if kdevplatform > 5.1 is required, because at least in recent opensuse distro there is no kdevelop-devel or kdevelop-kdevplatform-devel package (see https://build.opensuse.org/package/view_file/openSUSE:Leap:42.3/kdevelop5/kdevelop5.spec?expand=1) It would be easier to have a dedicated kdevelop-kdevplatform-devel, but this seems to be a distribution issue. > What you suggest makes sense, but the thing is that this requires the > kdev-php maintainer(s) to make some kind of API/ABI guarantee of the > exported functions, unless you want it to potentially randomly break every > three weeks. I guess this could be solved by installing related files into a version specific private folder similar to what Qt5 does. Those files are only valid for the given version and may be different on other versions. At a first look the header files from the build dir will fall into this category and should be installed into <include-dir>/kdev-php/private/x.y/ while the files from the source dir could got into <include-dir>/kdev-php ? cmake build system then needs to add this include path <include-dir>/kdev-php/private/x.y to the generated target interfaces in the cmake find package config files. > They need to be asked whether they can/want to do this ... I added the recent kdev-php maintainer to this bug, but did not get any answer. May be I should add Milian too ? -- You are receiving this mail because: You are watching all bug changes.
