Where does KAuth belong?

[Alexander Neundorf]

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

> > 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 ?
I had that idea too, but it seemed to me a bit too much for just a handful of 
cmake files.
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.

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.

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

Alex