On Wednesday 20 February 2013, Patrick Spendrin wrote: > Am 16.02.2013 18:48, schrieb Alexander Neundorf: > > Hi, > > First sorry for needing that long, the mail got into the wrong folder here. > > > we are doing quite some rework of the build system in the frameworks > > branch of kdelibs. > > > > Short version: please try to build one of the tier1/ libraries, e.g. > > itemmodels/ standalone, and let me know if everything works. > > Likely not, but please see later.
Ok. It would be great if one of you windows guys could give the frameworks branch of kdelibs a try. I'd actually say build and install kdeqt5staging and the tier1 and tier2 libs separately, so you see only those parts which are already in a quite good state. You may use the kdelibs/superbuild/ directory for building. It does just that. > > Longer version: compiler and build settings are not set anymore in > > FindKDE4Internal.cmake, but instead in the file KDECMakeSettings.cmake > > and KDECompilerSettings.cmake in extra-cmake-modules/kde-modules/. > > > > > > If you have a look at KDECompilerSettings.cmake, you will notice quite a > > few lines which are commented out. > > > > * There is something related to KDEWIN_Packager. > > What is this ? > > In which cases is it needed ? > > This can be dropped imho. Ok. > > * What's the status of the KDEWin library ? > > Is this needed by every application which wants to use some of the KDE > > (frameworks) libraries ? Or is it only needed for building some of the > > KDE frameworks libraries ? > > It is needed by some of the frameworks libraries, those that do not > fully rely on Qt but also on some of the posix C standard functions > (those that our compilers lack). Ok. > > * What is this manifest stuff for ? > > When is this needed ? > > The manifest is an xml snippet added into each binary to provide a way > to sign application binaries. CMake does this for all binaries on msvc, > but it doesn't do that on mingw. so it is still needed (if cmake doesn't > make it itself). Should cmake do that also for mingw or are there reasons why it shouldn't ? It sounds like something which could/should be solved in cmake itself. Does this sound reasonable ? Could somebody from the windows team try to get this into cmake ? To do that, join the cmake-develop...@cmake.org mailing list ( http://www.cmake.org/mailman/listinfo/cmake-developers ) and start discussing there. I'll try to help as much as I can. Alex _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel