Successful build of Krita on Windows with Emerge
Tags:
None
KDE Developer 
|
I took an interest in hacking at Krita and thought I might try getting it to work in Windows. I began by attempting the instructions on this wiki for building Calligra. This is the officially recommended way to build KDE apps on Windows. Naively following the instructions I was not able to get Krita to run, though I got through the process successfully. It was only after a little more research I found Boud's instructions for building Krita. Trying to use Cmake to do all the work of downloading and managing dependencies didn't go very well, but looking through the dependencies helped me figure out what I was missing for building Krita. I decided the best course of action would be to patch up Emerge following the dependencies specified in the Krita build instructions, and I was able to make it work successfully. If you want to hack Krita on Windows I would recommend trying this approach first.
The process is not fully tested yet so if anyone wants to give it a shot let me know if there are hang-ups. Most of the changes are just adding new packages and changing some settings for Emerge, e.g. setting it to download QT 4.8.6 instead of 4.8.5, and adding support for the eigen3 package. These instructions are for building a 64 bit version of Krita. Necessary and Recommended software
Building Krita on Windows using Emerge: First, read the instructions for building Calligra on the Wiki. You need to create a directory tree and tell the system where to find your compiler. We'll make a RelWithDebInfo build. Follow the instructions up to the step where we clone Emerge:
Then download and install this patch for the Emerge directory. I believe the command is "git apply Build-Krita-more-easily.patch." (Or use SmartGit!) Continue to follow the instructions for configuring Emerge. I've included a copy of the file kdesettings.bat with settings that worked for me, but you'll need to put in your own directory names. Check the half of the file carefully to make sure everything looks OK. You need to leave the buildtype as x86_amd64 for Visual Studio 2012, which isn't in the official instructions. Once everything is set up, we can run kdeenv.bat - this creates the build environment where we can run emerge. We'll download everything including the kitchen sink, because HDD space is cheap. Before we start, understand that this is a rocky procedure and after you get through this it's much easier. Here's a little documentation on Emerge. If you know Python you should have no problem tweaking it to work right, it's a brilliant little system. Here goes:
\kde\build\libs\qt-all\work\msvc2012-RelWithDebInfo-4.8.6\src\3rdparty\webkit\Source\WebCore\tmp\moc\release_shared which contains a chain of ..\..\..\..\..\ which is one too many. I just deleted one of the ..\ from each of the files, and it continued just fine. Perhaps you won't run into this error. I'm not quite sure how to correct this mistake. KDE also takes a while to build but it's more nicely behaved. Everything else is small and quite fast. We're not done yet though. After emerging coreutils, you'll want to go into /dev-utils/bin and delete link.exe and make.exe, since they can interfere with the Microsoft versions if they're in your system path. The reason we're separating the libraries into two groups is because the second batch gave me a little more trouble. They are working alright on my computer right now after making the changes you pulled from the patch, except for the last one.
Now that you have a healthy 10 gigabytes of dependencies to feed the Calligra suite it's time for the fun part: compiling Krita! Navigate to to /kde/git and check out the source:
Now I'm not sure what all of those cmake commands are for, but I know it makes a working configuration for me! I add a |tee krita_configlog.txt to the end of that to save the log. Then you'll run make/make install:
If you want, you can change "NMake Makefiles JOM" to "Visual Studio 11 Win64" or "Ninja." (You'll have to delete CMakeCache.txt before doing so.) Generating Visual Studio 11 files from CMake allows you to play around with Krita in the IDE. Using Ninja you can change the last two commands to "ninja" and "ninja install" and it will be significantly faster, but the output is less useful, so better to save that for after your first successful build, and you can use it to re-compile. I don't see any reason that Krita shouldn't compile "as-is." |
Registered Member
|
Wow! Thanks for writing this up. This must have taken quite some time to get going and write about. I haven't actually tried to build Krita on a Windows machine ( have done it a few times on linux). I might give it a shot between Boud's instructions and yours. It would be nice to have more people on Windows poking around at it.
|
|
KDE Developer
|
Yes, once I started poking around it became like a game. You get a cryptic failure message, decipher it, tinker with the code, then make it a little further. (Or more likely it derails at the same point and you keep on tinkering.) The percentage complete turns into your score.
If you do try it let me know, I'm very curious. |
KDE Developer
|
Hi Mike!
Good to see you got success with this approach. What I'm wondering about... Does g'mic work reliably for you with this build? If not, I'd be really interested in a build with mingw. I've tried all kinds of approaches, including cross-compiling, but I was getting so strapped for time that I had to give up for now... But for you it should be a simple matter of selecting a different compiler in emerge, right 
|
Registered Member
|
Nice, thanks for figuring all that out! I had attempted this a few months ago, but gave up out of frustration about 2/3 of the way through. I am glad you are more patient than I am
|
|
Registered Member
|
I have been trotting along ok trying to get this Windows build to work. I am trying the "Boud route" to building so far. I updated the CMake list so it pulls the dependencies (seems like it is working). I hit a snag when trying to build krita though. I am not sure how to decipher these error messages. The best I could find on the Interwebs was it has something to do with a EXE not being found when compiling. I am on Windows 8.1, so maybe file paths changed. What version of Windows are you guys using? This is just part of the message.
"C:\dev\YOURTREE\b\ext_krita.vcxproj" (default target) (1) -> "C:\dev\YOURTREE\b\ext_eigen3.vcxproj" (default target) (4) -> (CustomBuild target) -> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.ta rgets(172,5): error MSB6006: "cmd.exe" exited with code 9009. [C:\dev\YOURTREE\ b\ext_eigen3.vcxproj] "C:\dev\YOURTREE\b\ext_krita.vcxproj" (default target) (1) -> "C:\dev\YOURTREE\b\ext_exiv2.vcxproj" (default target) (6) -> "C:\dev\YOURTREE\b\ext_expat.vcxproj" (default target) (7) -> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.ta rgets(172,5): error MSB6006: "cmd.exe" exited with code 9009. [C:\dev\YOURTREE\ b\ext_expat.vcxproj] "C:\dev\YOURTREE\b\ext_krita.vcxproj" (default target) (1) -> "C:\dev\YOURTREE\b\ext_exiv2.vcxproj" (default target) (6) -> "C:\dev\YOURTREE\b\ext_gettext.vcxproj" (default target) (8) -> "C:\dev\YOURTREE\b\ext_win_iconv.vcxproj" (default target) (9) -> iconv.dir\RelWithDebInfo\win_iconv.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' [C:\dev\YOURTREE\b\ext_win_ iconv-prefix\src\ext_win_iconv-build\iconv.vcxproj] [C:\dev\YOURTREE\b\ext_win_ iconv.vcxproj] win_iconv.dir\RelWithDebInfo\win_iconv.obj : fatal error LNK1112: module mach ine type 'X86' conflicts with target machine type 'x64' [C:\dev\YOURTREE\b\ext_ win_iconv-prefix\src\ext_win_iconv-build\win_iconv.vcxproj] [C:\dev\YOURTREE\b\ ext_win_iconv.vcxproj] iconv.dir\RelWithDebInfo\win_iconv.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' [C:\dev\YOURTREE\b\ext_win_ iconv-prefix\src\ext_win_iconv-build\iconv.vcxproj] [C:\dev\YOURTREE\b\ext_win_ iconv.vcxproj] win_iconv.dir\RelWithDebInfo\win_iconv.obj : fatal error LNK1112: module mach ine type 'X86' conflicts with target machine type 'x64' [C:\dev\YOURTREE\b\ext_ win_iconv-prefix\src\ext_win_iconv-build\win_iconv.vcxproj] [C:\dev\YOURTREE\b\ ext_win_iconv.vcxproj] |
|
KDE Developer
|
Hi Scott,
That basically means you've mixed up x64 and x86 builds in one tree. So part of what you built is x86, part is x64. I'm afraid that that means that you basically have to start over. That's what I did when I got this error. |
|
KDE Developer
|
Hi Boud - g'mic does work reliably, it fails tests and crashes krita every time. I just got a chance to work on Krita this weekend and I just revved up a mingw build as we speak. Wish me luck. I saw that you posted on your blog about compiling the CMake version of Krita installer. I completely agree with you that cross-platform development needs to be much higher priority for Calligra. However I don't think reverting to CMake is necessarily the way to go. I'm not sure if you've poked at Emerge, but every time I've had a problem I've found that Emerge already offers a way to solve it. The entire thing is written in Python and it's a snap to customize, unlike CMake which runs on 85% voodoo as far as I'm concerned. Emerge calls cmake when necessary but accommodates arbitrary build systems. In fact, I think it could even be pretty straightforward to write an Emerge script which builds only the dependencies you've listed on your blog, inclusive of all the stripped versions, patches, binary installs, aliases and whatever else needs doing. Switching to the master branch of Emerge (which installs kde5/frameworks) will be another benefit of finishing the Qt5 port. Compared to the 4-13 branch which was committed over two years ago emerge has become much more polished. I checked out the Emerge repo and typed "emerge frameworks" and it installed Qt, KDE and everything without pausing. |
|
KDE Developer
|
I thought it might be useful to share some of my build notes here.
Scott: The first one will be helpful for you.
CMake flags for Qt Creator using MSVC 2012:
|
|
Registered Member
|
thanks for all of your responses. I will spend some time going through these tools and techniques. I am not really a programmer, so these things tend to take me a bit longer to learn and get through. Excited to take this information and give it another go. I will try the emerge route this time with Mike's suggestions.
|
|
KDE Developer
|
Let me know if you run into any trouble applying the patch. I've made a few more tweaks since posting the other version. This one separates a few additional changes I made. You should be able to check out kde-4.13 and do it all in Git immediately. https://dl.dropboxusercontent.com/u/160 ... _patch.zip As a reminder, on top of these things that were natural to fix programmatically there were a more tweaks in the Qt build I just did by hand, and I found it was easier to build OpenSSL, LibFFTW and update-mime-database separately. I recommend grabbing update-mime-database since the only thing you need is a working executable... just make sure to put it deep down in your path so you don't accidentally link your programs to the .dlls in the archive. https://dl.dropboxusercontent.com/u/160 ... _patch.zip https://dl.dropboxusercontent.com/u/160 ... atabase.7z Krita itself was pretty straightforward to attack after wrestling through Emerge. I can share a patch for that too, it probably won't fix much more than the handful of issues I kept in my notes: 1) The things I wrote down were that the very first line of \krita\cmakelists.txt needed to have the command "add_definitions" switched to "add_compiler_options", 2) vcmacros.cmake generated some cl.exe command lines for kritaimage.dll that were too long and I had to insert a few @<< into the makefile* 3) The einspline\nugrid.cpp needed to have the namespace boost::math:: written explicitly in front of the functions expm1 and log1p 4) I needed to comment out SetProcessDPIAware() in main.cc. *Another nice thing about Ninja is that it stacks the entire build command system into one file build.ninja, so whenever something goes wrong it's easy to locate the commands giving rise to the error, and it's easy enough to read that you can make small tweaks on the spot. |
|
Registered Member
|
I am not able to build on Windows 8.
c:\kderoot\emerge>kdeenv.bat kdesettings.bat executed KDEROOT : c:\kderoot KDECOMPILER : msvc2013 KDESVNDIR : c:\kderoot\svn KDEGITDIR : c:\kderoot\git DOWNLOADDIR : c:\kderoot\download The system cannot find the path specified. c:\kderoot> c:\kderoot>emerge qt emerge debug: buildAction: all emerge debug: packageName: qt emerge debug: buildType: RelWithDebInfo emerge debug: buildTests: False _____________________________________________________________ |
|
KDE Developer
|
I understand. The last post is already a little bit outdated. Can you share more information?
I suggest you try to build Krita with Qt5. The Emerge system is working much better on the latest branch than on older versions. Right now Krita on Frameworks is not ready to be used as a painting program, but there is no shortage of opportunity to fix changes and help complete the port. The Windows version comes out very close to the Linux version. Another change is that I recommend you use the Powershell version. Just run kdeenv.ps1. Powershell is a much saner environment in Windows and can be greatly enhanced with PSReadLine. This is by no means a "set it and forget it" build. You'll have to go in and try to fix errors, and if you come up with generalized solutions, push them as a patch. Hopefully these will be things that can be pushed to the master branch. Apply this patch to the "master" branch of Emerge. The goal is to make this patch smaller over time and contribute it upstream. https://dl.dropboxusercontent.com/u/160 ... erge.patch emerge qt emerge pkg-config emerge boost Make sure that you get Qt 5.5, earlier versions are very buggy. For now, you will emerge the necessary KDE frameworks one at a time. This will pull various things from Git. Most tests will not compile, so comment out tests folder from the cmakelists of KDecoration, kdelibs4support and Kross and "demo" in Oxygen. There is a nasty problem with KDocTools involving a CMake routine for encoding invoking a Perl script. The problem is that it replaces colons, e.g. c:\ will become c%3A\, and I do not know how to fix it except to remove the method entirely. There are probably other issues not covered by the patch. emerge karchive emerge kcodecs emerge kconfig emerge kcoreaddons emerge kguiaddons emerge ki18n emerge kitemmodels emerge kitemviews emerge kwidgetsaddons emerge threadweaver emerge kcompletion emerge kiconthemes emerge sonnet emerge kparts emerge kio emerge kxmlgui emerge kross emerge kwallet emerge kglobalaccel emerge kemoticons emerge kconfigwidgets emerge kdewin-lib emerge kdelibs4support emerge kross This is very cutting edge, so good luck. |
|
KDE Developer
|
So it's time i pass here too to ask help.
I've managed to compile Krita not with Emerge but with CMake, starting from boud kritadepwin project (and updating it). Now though i'm in a weird situation where starting Krita manually works fine, but through QtCreator it cannot load the plugins:
The funny thing is that THEY ARE THERE! Also i had the icons not loading but apparently setting KDEDIRS pointing to the install directory and KDEHOME to %APPDATA%\.krita made it work (note, again launching Krita manually worked fine). So i really don't know where to bash my head anymore, i have half Windows in the PATH directory, included those plugins dll (which shouldn't be needed).. and i really don't get what QtCreator is doing to make Krita not find those plugins. PS: Ok apparently writing this down made me really think the last things i didn't tried: ProcessMonitor by SysInternals.. With this i've found that it's not kolcmsengine.dll that is not finding but a dependency, namely lcms2.dll.. which it was searching in the current working directory.. set by QtCreator, which though pointed to a build folder instead of the install one, where the dll was present. |
|
Registered Member
|
I've been working on MinGW fixes for all the dependencies. I've documented the process so far in the kde-windows mailing list (archived here and here). I probably could have saved some time had I looked into your patch a bit earlier
. Great job there. However, I got things to compile with far fewer changes than what you've listed there, and I'd like to avoid unnecessary modifications, so I'm wondering about the reasons behind some of them. It might be a good idea to add some commentary to the patch explaining why each modification is made, so that new people can get up to speed more quickly. Might be a bit too laborious to do after the fact, of course.Your latest listing is missing: emerge eigen3 emerge lcms2 emerge exiv2 Exiv2 0.25 gives a linker error with mingw, but this can be fixed by adding TARGET_LINK_LIBRARIES( exiv2lib ws2_32 ) to the mingw section of exiv cmakelists. About the issues mentioned: If I got it right, when building kross, the metafunction doesn't get built into the krosscore dll (at least with mingw) so the test will also fail. Just disabling the test might cause some problems later on. I posted a quick fix to the mailing list thread. Tests for KDecoration and kdelibs4support build fine for me without modification. The KDocTools issue can be patched by adding colon character to the list of escaped characters in download\git\kdoctools\cmake\uriencode.cmake (assuming you are talking about the same thing). I ran into the same issue with kdelibs4support install script, and the same amendment worked there too. About building krita: I just got started with this yesterday. I'm assuming frameworks is the right branch to use for now (soon to be merged to master, apparently). I set jom to log and ignore errors, and did a full build. I got some "not declared in this scope" errors and missing include paths in few places. Nothing too major at first glance, although kritacolor seems oddly broken or unfinished(?), and apparently nothing depends on it(?). Can Krita be successfully compiled with MSVC at the current state? Stefano: You're compiling the pre-frameworks version, right? I'm getting a bit confused by all the variations we're dealing with here  .
|
Bookmarks
Who is online
Registered users: abc72656, Bing [Bot], daret, Google [Bot], lockheed, Sogou [Bot], Yahoo [Bot]
