Without exiv2, eigen3 and lcms2 Krita won't build at all, so I guess that must have gotten build transtively. You don't need kross or kdoctools for Krita.

I'm building Krita without emerge, with msvc 2012, all the time, but that's still the Qt4-based version of Krita, not the frameworks branch. My released packages of Krita for Windows are using the cmake subproject approach, kdelibs-stripped and the calligra/2.9 branch.

boudewijn wrote:Without exiv2, eigen3 and lcms2 Krita won't build at all, so I guess that must have gotten build transtively. You don't need kross or kdoctools for Krita.

That's good to know. At least it was a very enlightening bug-hunt .

boudewijn wrote:I'm building Krita without emerge, with msvc 2012, all the time, but that's still the Qt4-based version of Krita, not the frameworks branch. My released packages of Krita for Windows are using the cmake subproject approach, kdelibs-stripped and the calligra/2.9 branch.

I thought that was the case with stable builds. I'm not expecting anywhere close to full functionality from the frameworks branch, but I'm hoping to at least get to the point where I can successfully run it. I'm basically just setting myself up for some work that will begin maybe 1-2 years from now, so I'm trying to get familiar with the things that are most likely "the future of Krita". Currently my biggest issue is that I don't have clear enough idea just how functional it's supposed to be, and what things are working. That's why I was asking whether it even builds currently.

Antton T. wrote:Stefano: You're compiling the pre-frameworks version, right? I'm getting a bit confused by all the variations we're dealing with here .

Yes, the one coming from calligra/2.9; though i changed a bit the given CMakeLists, from kritadepwin, to rely less on other steps that the user should do, like manually changing the script itself to have it build/install things in different folders and instead have cmake do all the stuff while being able to change the behaviour through cmake options/defines.
I'm also able to compile with VS2013 (this is the last version compatible with Qt4.8 ).

Stefano Bonicatti wrote:So it's time i pass here too to ask help.
Starting Krita manually through QtCreator it cannot load the 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.

Did your debugging work out? My recommendation was going to be calling windbg (or gdb) from a shell so you have control over the path. It would be great to get the Visual Studio debugger working.

Antton T. wrote:I've been working on MinGW fixes for all the dependencies. 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.

MinGW and MSVC are going to break at different stages. I also found that MinGW needed fewer changes compared to MSVC. When I first tried out MinGW, I simply hoisted over the entire patch just in case, and didn't differentiate which parts were only necessary for MSVC. As long as it's compiling it's best to assume everything is OK. (As long as the final product is working!)

The Emerge repo doesn't get all its corners scrubbed like Krita's - meaning errors pop up pretty often - so I definitely recommend you submit fixes upstream. Yesterday I finally got around to splitting that patch into pieces and posting it to Review Board. Some of those changes are merged in already, but others will need a bit more discussion. You can see the remaining open changes on my profile.
https://git.reviewboard.kde.org/users/abrahams/

There are some small hacks involving Boost I haven't yet sorted out. Instead of working out those problems it might be worth simply updating it to the newer 1.58/1.59 instead of 1.55, since the latter is now over two years old.

Antton T. wrote:Your latest listing is missing:
emerge eigen3
emerge lcms2
emerge exiv2

Yes, the frameworks instructions didn't quite cover everything. A complete writeup in the Wiki would be nice. (=

Antton T. wrote: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.

Can you submit it as a patch to Emerge? I just pushed the update to version 0.25 to the master repo. Most likely thing you want to try is run emerge --createpatch and overwrite the old patch in the Portage folder.

Antton T. wrote: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.

Nice find. That also sounds good to submit upstream. These guys are also using Reviewboard so you have to submit it there.

Antton T. wrote: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?

No it's not quite there, I also work on top of a patch. One chunk of it that will cause the patch to shrink has blown up into a pretty comprehensive change in the repository at the moment. That may be the cause of the undeclared symbols you're seeing. https://phabricator.kde.org/T563 I can post a patch that works on MSVC once this is out of the way.

Other than the export definitions, I have to turn off a few testing directories and make some other changes. Again MinGW is a more forgiving so hopefully it should come together for you without too much trouble.

Antton T. wrote:Stefano: You're compiling the pre-frameworks version, right? I'm getting a bit confused by all the variations we're dealing with here .

Boud's CMake scripts are for KDE 4, so yes, that's right.


I also think you have reason for optimism: If you're got all the Krita dependencies built then you're already past the nasty part. Just keep the percentage completion bar ticking upward. =)

Mike A. wrote: Did your debugging work out? My recommendation was going to be calling windbg (or gdb) from a shell so you have control over the path. It would be great to get the Visual Studio debugger working.

Sorry for the delay, must check the forum more often!.

Yes i succeeded, i'm using cdb, just needed to fix the working folder of QtCreator in the run step.

Though is not perfect because i can only inspect local variables, while instead class fields and stuff hangs the debugger which complains about not finding symbols :S.
There i don't really know what to do because even if i copy all the .pdb in the Krita run folder and set in QtCreator the Symbol path to that folder in CDB Path, it still doesn't work.

And well, debugging from a shell is really a pain.. it's only good for very simple stuff or to get backtraces :\.

I've had some recent success using the Windows debugging tools like this: add to my debugging symbols path the directory where containing the .pdb files, for me that was r:\build\calligra\bin. Once that's set up, I can run "windbg krita," from the shell. Windbg is a very full featured debugger and does a fine job browsing source, though it doesn't have a great UI, you can do step by step debugging with the function keys.

Another thing that has worked from me: whenever I encounter a crash, I can click "debug" in the popup menu and start the Visual Studio debugger. It seems to know how to browse the source code, including Qt source. I haven't attempted to launch Krita directly through Visual Studio.

Here's the question I cannot answer: Visual studio in Windows versus Emacs + gdb in Linux.

One more update: yesterday I went through the build with MSVC 2015 and though it wasn't perfect, it was better and better. Qt Webkit and Boost were annoying but no more than usual, I disabled building tests for gsl, kdesignerplugin and kdelibs4support, and in a few places I needed to mess around with changes to the C standard library, which meant I was adding "#define tzset _tzset" and "#define tzname _tzname" and removing "#define snprintf _snprintf" in a few places. I'm going to try to push some of those changes upstream today.

Mike A. wrote:I've had some recent success using the Windows debugging tools. What I have done is this: set up my debugging symbols path to include r:\build\calligra\bin where the .pdb files are, then from the shell run "windbg krita," which launches windbg, a very nice debugger. Also, whenever I encounter a crash, selecting Visual Studio debugger has given me the ability to browse the source code, including Qt source. I haven't attempted to launch Krita directly through Visual Studio.[...]

If i can stay away from Visual Studio is better, i prefer QtCreator, the only issue i have is the debugger.
And well still WinDBG won't make it, because the point is that i want to have everything in the same place and i want to step the source code from the start, not only when it crashes.
Using WinGDB or Gdb it's like being half blind (as in, i miss informations like where i am in the source code, what are all the locals.. and all of this possibly in a "nice" and readable interface ).

Stefano Bonicatti wrote:Using WinGDB or Gdb it's like being half blind .

Windbg has source code, stack, locals, registers, etc. in the "view" menu.

Gdb, well, just launch it with Emacs. But that's what Qt creator and Kdevelop are for, when you start debugging with them, on the back end all they're doing is running an instance of gdb and showing the output in some nicely organized windows.

Mike A. wrote:Windbg has source code, stack, locals, registers, etc. in the "view" menu.

Gdb, well, just launch it with Emacs. But that's what Qt creator and Kdevelop are for, when you start debugging with them, on the back end all they're doing is running an instance of gdb and showing the output in some nicely organized windows.

I know but the problem is having two tools to do the job while one (the debugger) can really be in the background and i can save some "mental context switch".
But wait, Gdb on Windows? How? You mean the MinGW one? Never tried (i thought it would give problem if i wasn't using MinGW to compile).

Stefano Bonicatti wrote:I know but the problem is having two tools to do the job while one (the debugger) can really be in the background and i can save some "mental context switch".
But wait, Gdb on Windows? How? You mean the MinGW one? Never tried (i thought it would give problem if i wasn't using MinGW to compile).

I don't understand, two tools? When you're using a front-end like Qt Creator or Emacs, you shouldn't have to be thinking about the back end.

I was in fact referring to MinGW to do GDB on Windows... but you're right, Qt Creator does support a CDB back end on Windows too. http://doc.qt.io/qtcreator/creator-debu ... gines.html

Mike A. wrote:I don't understand, two tools? When you're using a front-end like Qt Creator or Emacs, you shouldn't have to be thinking about the back end.

I was in fact referring to MinGW to do GDB on Windows... but you're right, Qt Creator does support a CDB back end on Windows too. http://doc.qt.io/qtcreator/creator-debu ... gines.html

I think i did not explain it well enough and probably we are saying the same thing.
I'm just saying that i really don't like working with the debugger alone, or even with what's not an IDE, so i always want the debugger to be just a backend not a separate tool i have to run to debug.

That being said as far as i can see MinGW GDB is a bit old (as MInGW itself) and i don't think it works with msvc compiled binaries, so it's not a choice (unless i'm wrong).

Stefano Bonicatti wrote:I think i did not explain it well enough and probably we are saying the same thing.
I'm just saying that i really don't like working with the debugger alone, or even with what's not an IDE, so i always want the debugger to be just a backend not a separate tool i have to run to debug.

That being said as far as i can see MinGW GDB is a bit old (as MInGW itself) and i don't think it works with msvc compiled binaries, so it's not a choice (unless i'm wrong).

I agree. After experimenting with different options, I've concluded that even if you are working with your favorite tool, debugging is always painful.

About MinGW version: actually they keep it quite up to date. For example they ported GCC 5.2.0 on August 3rd, while the official release announcement was July 16th. I found that trying to build all the dependencies I ran into errors building some of the packages with the 5.0 series, I downgraded to 4.9.2 to get everything to build smoothly.

Unfortunately the resulting binaries seemed a tad slower than MSVC, so as long as you can get debugging to work I don't think there's reason to move away from MSVC. I think the major benefit of MinGW is not so much being able to use the GNU toolchain on Windows, but rather that you can cross compile to Windows from Linux machines. (Well, also software freedom, but that goes without saying. )

Mike A. wrote:I agree. After experimenting with different options, I've concluded that even if you are working with your favorite tool, debugging is always painful.

About MinGW version: actually they keep it quite up to date. For example they ported GCC 5.2.0 on August 3rd, while the official release announcement was July 16th. I found that trying to build all the dependencies I ran into errors building some of the packages with the 5.0 series, I downgraded to 4.9.2 to get everything to build smoothly.

Unfortunately the resulting binaries seemed a tad slower than MSVC, so as long as you can get debugging to work I don't think there's reason to move away from MSVC. I think the major benefit of MinGW is not so much being able to use the GNU toolchain on Windows, but rather that you can cross compile to Windows from Linux machines. (Well, also software freedom, but that goes without saying. )

Ah i think i've found the right MinGW, i was on this website http://www.mingw.org, where the last update is of 2 years ago, but i see that there's this http://mingw-w64.org/, that is updated.
Never used MinGW before so didn't know where to look and thought the first one was the only "correct" one.

Stefano Bonicatti wrote:Ah i think i've found the right MinGW, i was on this website http://www.mingw.org, where the last update is of 2 years ago, but i see that there's this http://mingw-w64.org/, that is updated.
Never used MinGW before so didn't know where to look and thought the first one was the only "correct" one.

You're completely right: I never realized there was a fork in the project. I simply used the version that Emerge installs automatically. They call it MinGW in the configuration files, and I think I overlooked the "64" as being due to my choice of a 64 bit toolchain.

So: all my advice in this thread applies to MinGW-w64, whereas I have no idea whether the original MinGW would work.