Fri Mar 05, 2010 3:23 pm
Although the installer may seem like it is a good thing to some users, I personally find it irritating and limited. There is no easy way to use your own compiler (mmingw-w64) with the kdewin package, and the installation dir is VERY easily cluttered, especially when trying to install src packages to compile yourself.
Why can't there be a tar.bz2 package for each of the large components, like:
* kdesupportlibs (jpeg, tiff, iconv...)
which are all easily configured for building and installing to a given prefix (eg: c:\kde) so that all the packages are installed in a central location after the build. This would make it a hell of a lot easier for developers to get a working installation. In my ideal packaging world:
- unpack kdesupportlibs
- cd to the source directory
- cmake -G"MinGW Makefiles"
- mingw32-make install
- all done: the headers, *.a libs and dll's are all installed to their directory (include, lib and bin respectively).
and repeat for other packages.
Why is this so necessary? Well, mingw(-w64/-w32) cannot be told where to look for libs and headers, and instead relies on its own <mingw(-w64/-w32)installdir>\mingw directory for includes and import libs. My approach would greatly simplify this short-coming, and allow other programs, like kile and amarok to be compiled in a x64 environment.
Any thoughts, or am I missing these simple to use packages somewhere?
Sat Mar 06, 2010 1:57 am
In KDESupport, an "emerge" system exists which appears to be used by the KDE Windows team. Unfortunately I don't know how to use this, you may wish to try asking on email@example.com or #kde-windows on Freenode.
System Settings and Device Actions KCM maintainer
Mon Mar 08, 2010 6:03 pm
There's also more information about building KDE on Windows in Tech Base. You can find links to it from the KDE for Windows website: windows.kde.org
airdrik, proud to be a member of KDE forums since 2008-Dec.