How to debug or run Sigil's source code in VS2017

[darencainiao]

I am a graduate student.I want to learn the source code of sigil.
I have successfully built the installation package for sigil.Now,I want to debug sigil so that I can understand the source code in VS2017.But I failed.
I download the source code of sigil from github and try to import it into VS2017 by import CMakeLists.But I don't know what to do next.What should I do afterwards?

[darencainiao]

in windows

[DiapDealer]

I don't use Visual Studio's IDE to build or debug Sigil's official Windows releases. I only use the command-line tools. I try to make sure that cmake can be used to generate VS IDE project files, but that's about it. Hopefully, someone who actually uses the IDE can offer some help.

[darencainiao]

Originally Posted by DiapDealer

I don't use Visual Studio's IDE to build or debug Sigil's official Windows releases. I only use the command-line tools. I try to make sure that cmake can be used to generate VS IDE project files, but that's about it. Hopefully, someone who actually uses the IDE can offer some help.

Thank you very much for your answer.
I would also like to ask how do you debug sigil if you do not use Visual Studio's IDE? Is it using Qt's qDebug() function? As far as I know, references to classes in C++ is somewhat confusing, and it will be difficult to debug and find bug
without step through in Visual Studio's IDE.By the way, would it be better to debug sigil in Linux?

[DiapDealer]

Originally Posted by darencainiao

Is it using Qt's qDebug() function?

For quick stuff on Windows, yes. There's already a lot of debug information that that can output to a file (by putting a user-writable file path in the SIGIL_DEBUG_LOGFILE environment variable) and by setting any of the #define DBG if(0) directives found at the top of many files to #define DBG if(1). Any qDebug() statements you add will also be output to the log file defined by SIGIL_DEBUG_LOGFILE.

Originally Posted by darencainiao

As far as I know, references to classes in C++ is somewhat confusing, and it will be difficult to debug and find bug without step through in Visual Studio's IDE.

I personally find Visual Studio's IDE/debugger to be terribly confusing, bloated and nearly unusable. Plus, you need a Microsoft account to even open the IDE. So I don't use it.

Originally Posted by darencainiao

By the way, would it be better to debug sigil in Linux?

For any kind breakpoint or backtrace work, yes. At least I find it to be better, anyway. Almost all of my development work on Sigil is done on Linux. I typically find that bugs/crashes in Windows Sigil will often be duplicated in Linux Sigil. The command-line debugging tools of Linux are infinitely more familiar/intuitive/simple for me.

Another part of the problem is that Sigil on Windows will not run from its build location without a lot of extra wrangling. It needs to be installed because of its bundled Python dependencies. So running Sigil with the debugger and stepping in/out/through are problematic. Heck, just building a debug version of Sigil is difficult on Windows because of the embedded Python portions. It wants a debug version of Python as well.

[darencainiao]

Originally Posted by DiapDealer

For quick stuff on Windows, yes. There's already a lot of debug information that that can output to a file (by putting a user-writable file path in the SIGIL_DEBUG_LOGFILE environment variable) and by setting any of the #define DBG if(0) directives found at the top of many files to #define DBG if(1). Any qDebug() statements you add will also be output to the log file defined by SIGIL_DEBUG_LOGFILE.


I personally find Visual Studio's IDE/debugger to be terribly confusing, bloated and nearly unusable. Plus, you need a Microsoft account to even open the IDE. So I don't use it.


For any kind breakpoint or backtrace work, yes. At least I find it to be better, anyway. Almost all of my development work on Sigil is done on Linux. I typically find that bugs/crashes in Windows Sigil will often be duplicated in Linux Sigil. The command-line debugging tools of Linux are infinitely more familiar/intuitive/simple for me.

Another part of the problem is that Sigil on Windows will not run from its build location without a lot of extra wrangling. It needs to be installed because of its bundled Python dependencies. So running Sigil with the debugger and stepping in/out/through are problematic. Heck, just building a debug version of Sigil is difficult on Windows because of the embedded Python portions. It wants a debug version of Python as well.

Thank you very much again for your reply.
A few days ago, I successfully built Sigil software in Ubuntu according to the method provided on Github.After successful built, I obtained a sigil software.But I still don't know how to debug sigil in linux right now.I see you mentioned earlier that The command line debugging tools of Linux.Can you explain this thing in detail?Forgive me for not being particularly familiar with Linux systems.Or is there a way to understand the source code of sigil without debugging it？

[DiapDealer]

I'm not really the one for giving detailed instructions on using the Linux gdb command-line debugger. My teaching skills are not great. As for learning Sigil's code; everyone's different. There's no shortcut for getting your head wrapped around a million+ lines of code. You just need to dive in somewhere. I learned it in small chunks by studying the code in relation to a very particular aspect I wanted to change, or a very particular bug I wanted to locate/fix. Lots of individual little pictures, rather than trying to grasp the whole picture at once.

If you get lost looking for where something in particular happens in Sigil's code ... ask.

[rkomar]

ddd is a graphical front-end to gdb. I found it especially useful for visualizing the contents of structures. When you hover your mouse over a variable, it displays the value it contains in a popup. That really sped up visualizing the current state of the program for me. Of course, it also makes stepping, handling break points,... (the usual debugger stuff) more convenient than typing into the command line. It isn't an IDE, but it might be helpful to a linux debugging newbie.

[DiapDealer]

Thanks for the input! Not being a gdb guru myself, a graphical front-end might be useful to me as well. I'm OK with graphical "frontends" to individual tools. It's full-blown IDEs that I've learned to steer clear of.

[darencainiao]

Thank you for your answers