kdelibs frameworks buildsystem under Windows

[Alexander Neundorf]

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