Where does KAuth belong?

[Dario Freddi]

On Thursday 15 September 2011 12:38:15 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

Chiming in on the original question, I confirm the fact that KAuth itself does 
not hard-depend on anything. Although, building KAuth without any backend (and 
nowadays the choice is pretty much the same for all distros) makes it useless. 
On the level of dependency decision, I let the knowledgeable guys decide :)

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

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110917/e95462c7/attachment.sig>