Where does KAuth belong?

[Stephen Kelly]

Alexander Neundorf wrote:

> On Thursday, September 15, 2011 12:04:24 AM Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>> > On Tuesday, September 13, 2011 09:41:31 PM Stephen Kelly wrote:
>> >> Forwarding to kcd which is probably more appropriate.
>> >> 
>> >> Stephen Kelly wrote:
>> >> > Hi,
>> >> > 
>> >> > KAuth became a tier1 library in the last week. It's nice to see it
>> >> > separated out.
>> >> > 
>> >> > However, it depends on Polkit-Qt, which is in `kdesupport` in the
>> >> > KDE 4 world currently.
>> >> > 
>> >> > Polkit-Qt seems like something that would become a tier1 library if
>> >> > that's what its developers go for.
>> >> > 
>> >> > That would make libkauth tier2, right? I'll move it to the tier2
>> >> > directory soonish unless someone else does, though that in itself
>> >> > doesn't mean much.
>> >> > 
>> >> > The tier1/2 subdirectories will likely go away when each library
>> >> > becomes its own git repo I guess.
>> >> > 
>> >> > Then tier1/2 distinction will only be a matter of documentation
>> >> > (possibly -- Actually I don't think it's a distinction that should
>> >> > be
>> > 
>> > Yes, I think we will not really have three levels of dependencies, but
>> > basically a full dependency tree between the libs.
>> > 
>> > Should there still be something which makes some library/application a
>> > "KDE" application ?
>> > Right now it is linking against kdecore basically (which includes using
>> > the KDE cmake macros).
>> 
>> I'm not sure. I'm sure something obvious will fall out of the refactoring
>> work. There will be some kind of integration library at some (high up)
>> level which depends on the stuff that today is kdelibs. Presumably
>> applications using that will be KDE applications.
>> 
>> > Which is related to the question where the macros and settings from
>> > FindKDE4Internal.cmake and KDE4Macros.cmake will go.
>> 
>> Stuff like kde4_add_executable and kde4_add_library should get kde5
>> equivalents I think, even if it's as simple as
>> 
>> macro(kde5_add_library)
>>   add_library(${ARGN})
>>   generate_export_header(${ARG1})
>> endmacro()
> 
> But I wouldn't use the prefix "kde5".
> Since there is no KDE5.
> The prefix should be kdelibs5 or kf5 or kf1 I think (I still think since
> this will be the first version of the frameworks it should be kf1, and it
> would keep people from talking about KDE5, maybe).

I'd be ok with kdelibs5_add_library.

> 
>> > The stuff in there is really KDE-specific (e.g. the way we install
>> > icons, and how we figure out compiler flags, etc.).
>> > Will there be a KDEStuff.cmake in extra-cmake-modules ?
>> > 
>> > But it doesn't really belong there, it belongs to the basic "KDE"
>> > component. Will there be something like that ?
>> > A libkcore ?
>> 
>> How about a KDEBuildsystem module in frameworks, which contains the KDE5
>> equivalents of kde4Defaults, KDE4Macros etc? KDE5 applications will want
>> to use those things and maybe some frameworks will too.
> 
> You mean a separate git repository ?

Yes.

> I had that idea too, but it seemed to me a bit too much for just a handful
> of cmake files.

Maybe true.

> Beside that, it really seems like the right thing.
> Or put them together with "what makes up a KDE application".
> Maybe the basic tier2 module.

Or higher up. I always thought that on top of frameworks (which is for 
everyone) there would be an integration level for 'KDE applications' which 
uses 'KDE stuff' and 'KDE integration built in' - KApplication, kde 
convenience cmake macros, make sure ksycoca is run, KIcon, KUrl etc.

That's what 'KDE applications' would port to and the 'total interface' to it 
would be very similar to what the KDE4 kdelibs provides currently.

> 
> Are you aware that we have in kdesupport also projects which depend on
> each other (all depend on automoc, ok not anymore), then the strigi stuff,
> and the different phonon repositories. But this doesn't make those
> depending projects tier2 projects yet.

Yes, the tier1/2 stuff is useful for classification getting started and 
identifying useful stuff, but it remains to be seen what it will really 
mean.

> 
>> How is the way we figure out compiler flags different to how others do
>> it?
> 
> One thing is that FindKDE4Internal.cmake does something which is not
> recommended by CMake: if you do
> find_package(KDE4)
> it sets your compiler flags automatically.
> A cmake-conform cmake-module should not change any settings, it should
> only fill variables with contents (e.g. KF5_CXX_COMPILE_FLAGS), and then
> the using application can decide whether it uses them or not.
> 
> But, to make development easier for KDE developers, we do that
> automatically. This is also part of what makes an application a KDE
> application.
> 
> We shouldn't expect from all our developers that they suddenly take care
> of all that themselves.

Every KDE application I have seen has this boilerplate:

find_package(KDE4 REQUIRED)
include(KDE4Defaults)
include(MacroLibrary)
include(CheckIncludeFiles)

Why don't we set the flags in KDE4Defaults?

Are you recommending that if I do this (kitemmodels is a separately 
buildable and installable framework in the frameworks branch. Find it in 
tier1): 

find_package(kitemmodels REQUIRED)

that it should set compiler flags?

Steve.