Where does KAuth belong?

[Alexander Neundorf]

On Friday, September 16, 2011 02:07:23 PM Stephen Kelly wrote:
> 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.
> >> >> 
...
> >> 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.

Ah, ok.

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

...so you would do

find_package(kitemmodels REQUIRED) 
which sets a bunch of include dir and libs variables, and then

include(KDE4Defaults)
which sets compilers flags etc.

I think this sounds quite good.
We could also rename that file to UseKDE4.cmake, so it is similar to 
UseQt4.cmake.

Still, where will the file KDE4Defaults.cmake (or UseKDE4.cmake) be located ?

Alex