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
signature.asc
Description: This is a digitally signed message part.
