Move kde-config to kde4support.
Alexander Neundorf
neundorf at kde.org
Fri Feb 22 17:38:39 UTC 2013
On Friday 22 February 2013, David Faure wrote:
> On Thursday 21 February 2013 11:55:37 Alex Merry wrote:
> > On 21/02/13 11:24, David Faure wrote:
> > > For others on the list: I agree that a pure-Qt tool will be useful too,
> > > but it won't give us "--prefix, the prefix where KF5 was installed",
> > > for instance. And kf5-config is useful for compatibility (easier
> > > porting from scripts that use kde4-config). So let's have both (and at
> > > that point, we can deprecate the parts of kf5-config which are
> > > superseded by the pure-Qt tool).
> >
> > Is the intention to require all KF5 libraries to be installed to the
> > same location? If not, exactly what will "kf5-config --prefix" return?
>
> Good point. It will return the location where kde4support is installed :-)
> I see it as a "past looking" tool for compatibility, not as a correct kf5
> solution (which is why it's in kde4support).
I have to disagree here.
If you do
find_package(KF5 COMPONENTS kidletime kauth kconfig)
it will search the kidletime library, and once it has found it, it will search
kauth and kconfig only in the same prefix.
If KDEDIRS is set, it searches afterwards also in those.
This was the conclusion from the last time we discussed this here.
I also don't see why we should give this up completely.
Again, this is not black and white.
It is not "have one big blob of libs" vs. "have a myriad of libraries which
are completely independent and can be mixed and matched at will".
We will not only have tier1 libs, which have no dependencies to other kf5
libs.
There will be dependencies between the libraries, and I guess e.g. kconfig
5.4.3 will want to depend on kcoreaddons 5.4.3 or at least kcoreaddons 5.4.
Or am I wrong with this, will the libraries have potentially completely
individual version dependencies ?
Imagine the following: my system has kf 5.3 installed, and for some project I
want to use a subset of the kf5 libraries, let's say sonnet and kconfig, with
all their dependencies, from 5.5.
I would want to install those into a separate prefix, e.g.
/opt/my-kf5-5.5/, and when using it, I would want to make sure I get just what
is installed there, and not any other versions mixed in.
This works as it is now:
find_package(KF5 MODULE COMPONENTS KConfig Sonnet)
It will find KConfig and Sonnet only from the same directory, which will be
the prefix I installed them to.
If I want to mix different prefixes, I can use KDEDIRS (or could be KF5DIRS).
Or I can use them as independent libraries:
find_package(Sonnet NO_MODULE)
find_package(KConfig NO_MODULE)
IMO this will make using the kf5 libs easier, and keeps us a bit from
dependency hell. Why should we give this up ?
> > Incidentally, if we install pkg-config files, "pkg-config
> > --variable=prefix k18n" or similar should provide this...
>
> pkgconfig files are for developers, they might not be installed for end
> users.
Yes, pkgconfig files are part of the devel package.
Beside that, we will not install them, we install cmake Config.cmake files
instead. Those are more powerful, and make it possible to use the libraries
straight away with cmake.
Alex
More information about the Kde-frameworks-devel
mailing list