David Faure wrote:
> After my presentation on KDE Frameworks at the Dev Days, the obvious
> question "where do we download this from" came up -- especially for
> KArchive.
>
> So I took some time afterwards and prepared a self-contained
> KArchive-for-qt4 release.
>
> This pointed out some inter
David Faure wrote:
>> Also, if you don't use the feature_summary() function from
>> FeatureSummary.cmake, then you don't have to use
>> set_package_properties().
>
> Oops, oversight.
>
I just looked through the zip. Do you have an updated version with some
issues fixed/removed?
>> You use the
> [: David Faure :]
> Yes, please compile whatever you have ;)
Ok, I pushed it.
> I'm a bit surprised that ki18n depends on kservice, since kservice wants
> to depend on i18n (automatic catalog loading). I guess ki18n uses plugins,
> so the fix will be to port that to "pure Qt" plugin loading ins
On Sunday 18 November 2012, David Faure wrote:
> On Sunday 18 November 2012 18:21:49 Alexander Neundorf wrote:
> > Hi,
> >
> > is currently actually anybody using an installed kdelibs from the
> > frameworks branch ?
>
> Steve and Sput are regularly compiling kdepimlibs-frameworks AFAIK (which
>
Alexander Neundorf wrote:
> The code for creating a Config.cmake file is not trivial, but IMO also not
> boilerplate, and Stephen agreed in Berlin that this will have to be done
> individually be every project. This is the added
> threadweaverConfig.cmake.in and the call to
> configure_package_con
On Sunday 18 November 2012 00:28:35 Chusslove Illich wrote:
> I have now split out ki18n, made sure that kdelibs compile and that KLocale
> and KLocalizedString tests work, and have it as single humongous patch.
> Should I just commit it, or something else? I attach only the diff to
> kdecore/CMake
Alexander Neundorf wrote:
>> the variable for includes is not complete. you include most bits by
>> doing include , but threadweaver/foo includes
>> "threadweaver_export.h", so the threadweaver_INCLUDE_DIR variable isn't
>> complete enough. I needed
>> include_directories(${threadweaver_INCLUDE_DI
On Sunday 18 November 2012 18:21:49 Alexander Neundorf wrote:
> Hi,
>
> is currently actually anybody using an installed kdelibs from the frameworks
> branch ?
Steve and Sput are regularly compiling kdepimlibs-frameworks AFAIK (which
depends on kdelibs-frameworks).
> I mean, I think it doesn't
Alexander Neundorf wrote:
>> this is because the string "threadweaver" refers to the imported target
>> with the name "threadweaver".
>
> I would also see this as a hint that we should use a namespace for the
> exported target, so the line wouldn't be
>
> set(threadweaver_LIBRARY threadweaver)
>
Sune Vuorela wrote:
> On 2012-11-15, David Faure wrote:
>> This pointed out some interesting issues, especially in the cmakelists. I
>> removed the dependency on ECM, and as a result I saw many things for
>> which I thought "this should be in upstream cmake". Especially the
>> LIB_INSTALL_DIR stu
Hi,
is currently actually anybody using an installed kdelibs from the frameworks
branch ?
I mean, I think it doesn't work at all currently.
It can't be found via
find_package(KDE4)
since it doesn't install a kde4-config, and RPATH was also broken.
Alex
___
Hi,
in the next days I'll update the required cmake version for e-c-m and the
kdelibs framework branch to 2.8.10.1
(http://www.cmake.org/cmake/resources/software.html).
This makes it possible to install targets from one project in multiple export
sets. With this in place, we'll be much closer
On Sunday 18 November 2012, Alexander Neundorf wrote:
> On Saturday 17 November 2012, Sune Vuorela wrote:
> > On 2012-11-17, Alexander Neundorf wrote:
> > > On Thursday 15 November 2012, Sune Vuorela wrote:
> > >> On 2012-11-15, Alexander Neundorf wrote:
> > >> >> I thought we earlier agreed on t
On Saturday 17 November 2012, Sune Vuorela wrote:
> On 2012-11-17, Alexander Neundorf wrote:
> > On Thursday 15 November 2012, Sune Vuorela wrote:
> >> On 2012-11-15, Alexander Neundorf wrote:
> >> >> I thought we earlier agreed on things like "you should not inherit
> >> >> sonames from other mo
14 matches
Mail list logo
