I actually don't know how to compile Krita in Debug, as I am currently only focused on "improving" the Windows build process.

To compile Krita itself in Debug, my uneducated guess would say that setting CMAKE_BUILD_TYPE to Debug should be enough, unless the CMake files are actually setting custom compiler flags. IIRC there are some other options to enable more Krita-specific debugging stuff but those are not required?

The 3rdparty deps are added to the build system by ExternalProject. How to compile them in debug depend on what build system they use.
If the dep uses CMake, change the Add_ExternalProject call to pass CMAKE_BUILD_TYPE to the child CMake. I don't really remember if it is inherited automatically, but better be safe I guess.

Code: Select all

ExternalProject_Add(ext_xxx
   [...]
   CMAKE_ARGS
      -DCMAKE_BUILD_TYPE=Debug # or pass ${CMAKE_BUILD_TYPE} to use the same build type as the root project
)

Some deps like Qt and boost use their own build system, you'll have to refer to those and set the corresponding command line flags in the Add_ExternalProject call.
But beware that some libraries use a different output name for debug builds, you may have to fix those in some way.
(Note that some CMake generators may not use CMAKE_BUILD_TYPE for selecting build config, such as the Visual Studio ones)

With mingw you should be able to safely mix debug and release binaries (there isn't a real distinction of these in gcc, just different optimization levels and whether to generate debug info) so you could just build one of the deps in debug, in your case just swap in a debug Qt build (frankly I think you can just replace the DLLs, but I've never tried that yet so I'm not sure.)
It's a different story with MSVC, since it by default generates Debug and Release object files with incompatible linking modes, and they also link to different VC runtimes.

Do note that Krita works best with a patched Qt, and it is automatically patched if you build 3rdparty/ext_qt. If you want to build Qt manually (e.g. to build both debug and release binaries together) you'll have to patch the source code too. Refer to the CMakeLists.txt.

To compile Krita itself in Debug, my uneducated guess would say that setting CMAKE_BUILD_TYPE to Debug should be enough

Well. You're right actually (this is the case in windows, but I believe it should be the same for linux as well).

Previously I mentioned about a cmake variable inside CMakeLists.txt in the krita root source directory called "CMAKE_CXX_FLAGS_KRITADEVS". I'm not sure why I got the debug info to show up in a rebuild in linux, but now I'm pretty sure it's never used (since it was only declared and never referenced anywhere else).

Anyhow, I couldn't get krita to build in Debug mode, and have submitted a bug report: https://bugs.kde.org/show_bug.cgi?id=369303. I wouldn't call it a serious bug, but it's just inconvenient to develop when the debugger frequently shows <optimized out>.

Do note that Krita works best with a patched Qt, and it is automatically patched if you build 3rdparty/ext_qt.

Ah - that I'm aware. I've went through the CMakeLists.txt file in ext_qt before.

Also, as a side note, I've built all the 3rd party libraries in Release mode, but Qt and boost binaries didn't change at all. As you mentioned - these guys used a different build system, but it doesn't matter; the 3rd party libraries have shrunk considerably. This should probably speed up Krita now the 3rd party binaries have shrunk (from 700Mb to 400Mb). I still am not sure why 3rd party libraries are built in RelWithDebInfo though. As far as I know, RelWithDebInfo enables you to attach a debugger on your executable, and pinpoint the error into the specific location in the source code files. For myself, I think I don't really need that for 3rd party libraries.

I could be wrong.

It's a different story with MSVC, since it by default generates Debug and Release object files with incompatible linking modes, and they also link to different VC runtimes.

This is also off topic, but MSVC has been abandoned isn't it? I've googled around and I read that it had to do with GMic. In KRITA_SOURCE_ROOT\packaging\windows\build.bat it is still using MSVC though. I have written a build batch script (https://gist.github.com/bruceoutdoors/7c1a3f6b1b58cd9bee1502db205776aa) that uses MinGW and ninja, cause I would just leave everything to run overnight (maybe I can contribute that?).

Bruceoutdoors wrote:

It's a different story with MSVC, since it by default generates Debug and Release object files with incompatible linking modes, and they also link to different VC runtimes.

This is also off topic, but MSVC has been abandoned isn't it? I've googled around and I read that it had to do with GMic.

Kind of, from what I remember it was the case that MSVC didn't support OpenMP which makes gmic slow and that it crashes rather often. It may have changed or is fixable in some way but I have absolutely zero interest in making Krita compile with MSVC at the moment.

Although the original intention was (IIRC) to allow cross-compiling from Linux using mingw-w64, boud somehow couldn't make it work with Vc 1.2 and has to go back to building on Windows (but with a different compiler.) It's kind of funny.

By the way, how about discussing on IRC? You can find me as windragon sometimes.

By the way, how about discussing on IRC? You can find me as windragon sometimes.

Warning: me complaining about IRC

I used IRC when I first started out (well, it's not that long ago really). My gripes about it being that you have to be logged in to get messages. You can't just drop a message and the receiver gets it instantaneously half way across the globe via push notifications. Also messages don't stay; if you went offline you miss out what other people say. Sure, with an android app it is possible to be online all the time, but I'm not so keen on the options available (not to mention how much battery it'll need to be constantly listening for new messages). It's also an issue to branch out to different topics; an IRC chat room is like a small room with many people talking concurrently on a variety of topics. It's a bit like a fish market (sorry IRC lovers). You can't select a handful of people and take them to another room to talk on a specific topic.

It's not to say IRC is a poor choice; I mean, it's still a popular pick for open source developers today so I'm sure there's a good reason to still use it. It's just that having used something like Slack (which is what the Google Polymer team uses), using IRC is like a step back for me IMHO.

But sure, if I happen to pop in IRC we could chat there. I use the same handle all the time: bruceoutdoors (well, if it is available for me to use that is).

So you can understand why using a forum would be my preferred choice for the time being. Not only that, people who faced the same question can come here to find what they need. These forums are indexed by search engines after all.

There are currently the forum, mailinglist and IRC chat. Each has their own advantages and disadvantages so the communication flows over different channels. For example bigger development topics or complicated discussion usually go over the mailinglist. Many users are however not familiar with mailinglists so their communication is mostly over the forum.

The advantage of IRC is usally this fish market. Someone comes in and ask a questions. With 120+ people watching the is a good chance that someone might answer it. The IRC chat is intentionally not logged and searchable, we discussed that in the past. Users might still log it, but there is no official logging.

Actually, MSVC was abandoned because it couldn't support G'MIC AND VC. Now, that it can't support G'Mic isn't much of a suprised. G'Mic has it's own built-in script parser which is designed in such a way that on windows it needs a gigantic stack. The only thing G'Mic seems to built with is MXE.

VC, which allows us to use SIMD instructions for all the color maths (blending modes, composite ops, filters), does make a huge speed difference on windows. It is also, however, a really modern template-heavy c++ library, so we're literally switching compilers for this library alone.

TheraHedwig wrote:Actually, MSVC was abandoned because it couldn't support G'MIC AND VC. Now, that it can't support G'Mic isn't much of a suprised. G'Mic has it's own built-in script parser which is designed in such a way that on windows it needs a gigantic stack. The only thing G'Mic seems to built with is MXE.

Yeah I guess you're right.

Bruceoutdoors wrote:complaining about IRC *snip*

slangkamp had already said it most. The most important point to me is to be able to chat in real time and make conversations / q&a with short sentences about stuff that really doesn't need logging, unlike on forums that it may take a few hours to get feedback, and having to type a lot at once to get the point across clearly,

For example if you have a compilation problem, on IRC I can ask a few quick questions to do a quick troubleshoot; if it is on the forum I might have to ask a whole bunch of questions at once not even knowing if they would be helpful at all, and it would take some time until I get a reply, and then some more time before I can write a follow-up reply, you get it.

Besides, if there is anything important that needs to be logged, it would be written more clearly and then posted to a suitable place: bugzilla, mailing list, wiki... these sort of places.

Actually, MSVC was abandoned because it couldn't support G'MIC AND VC

I snoop about VC github repo. MSVC support is underway, but I think most of us (including me) couldn't care less. Idk. The only plus of using MSVC I see is visual studio + visual assist, but Qt Creator works pretty great for me (there's also CLion. Not sure if anyone here uses it?) .

There are currently the forum, mailinglist and IRC chat.

Hm. Now that you guys talked about it, I am seeing the point of IRC.

I actually never took notice of the mailing list until you mentioned it. It only seems to give me reports from Jenkins CI. I noticed mails from @alvinwong as well (recent), but no one seems to be replying... Yet.

My observation is that more of the development talk is happening in phabricator now. I actually prefer that; it's far nicer to track things there. Maybe in the future Jenkin reports would also be in phabricator. Will phabricator replace mailing lists?

Just FYI, I fiddled a new packaging script (packaging/windows/package_2.cmd) which splits the debug info instead of just stripping them. That way Krita runs faster when not debugging but still allows you to attach gdb to it later and use debug information. Of course if you attach gdb from the beginning it will still be slow.