Feature Request: export to callgrind from CLI

[ducklin5]

Firstly, thank you for this project! I use verysleepy primarily to get a callgrind.capture file that I can pass to qcachegrind. The UI process is tedious. I'm trying to automate it in a script file. Is there a way to enable exporting to a callgrind file without opening the UI. I tried the -o flag but that exports in .sleepy format. Note: migrated from discussion https://github.com/VerySleepy/verysleepy/discussions/118

[CyberShadow]

I don't think so, but PRs welcome!

[ducklin5]

Would be happy to contribute once I have time. Please can you direct me to where the CLI logic is?

[CyberShadow]

Yes, here is the entry point for parsing command line arguments:

https://github.com/mojomojomojo/verysleepy/blob/a804ae7f8ce41fc0a4e3170ad395fa2f4b26fb86/src/wxProfilerGUI/profilergui.cpp#L701

However, the export logic is in the "second half" (the result viewing window, mainwin.cpp), so implementing this feature may require a little bit of refactoring.

[ducklin5]

Spent all weekend trying to get the project to build with no luck.

I keep getting the following error when I run the build script:

Project "C:\Users\XXXX\verysleepy\sleepy.sln" (1) is building "C:\Users\XXXX\verysleepy\thirdparty\wine\dlls\dbghelp\vs\dbghelpw.vcxproj" (2) on node 1 (default targets).

C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(456,5): error MSB8020: The build tools for Visual Studio 2013 - Windows XP (Platform Toolset = 'v120_xp') cannot be found. To build using the
v120_xp build tools, please install Visual Studio 2013 - Windows XP build tools.  Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [C:\
Users\XXXX\verysleepy\thirdparty\wine\dlls\dbghelp\vs\dbghelpw.vcxproj]

I installed Build Tools for Visual Studio 2013 but that didn't work so tried installing VS13. I'm on Windows 11 and I keep getting this error in the VS2013 installer:

Windows Program Compatibility mode is on. Turn it off then try Setup again

(Compatibility mode is not even on though)

Next, I tried to build from IDE (VS2022) but I kept getting this error:

>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(456,5): error MSB8020: The build tools for Visual Studio 2010 (Platform Toolset = 'v100') cannot be found. To build using the v100 build tools, please install Visual Studio 2010 build tools.  Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution".

Really not sure why the IDE and CLI have different demands. Anyway, next I installed VS 2010 as apparently this is the only way to get Build Tools for Visual Studio 2010.

When I opened the solution in VS2010: dbghelw and wxWidgetsSetup couldn't be loaded

When I opened the solution in VS2022 (now with 2010 build tools available): all the projects loaded in but compiling results in some strange errors:

5>src\wxProfilerGUI\profilergui.cpp(646): error C2143: syntax error : missing ',' before ':'
5>src\wxProfilerGUI\profilergui.cpp(646): error C3531: 'tid_h': a symbol whose type contains 'auto' must have an initializer
5>src\wxProfilerGUI\threadsview.cpp(152): error C2143: syntax error : missing ',' before ':'
5>src\wxProfilerGUI\threadsview.cpp(152): error C2530: 'tn' : references must be initialized
5>src\wxProfilerGUI\threadsview.cpp(330): error C3499: a lambda that has been specified to have a void return type cannot return a value
5>src\wxProfilerGUI\threadsview.cpp(331): error C3499: a lambda that has been specified to have a void return type cannot return a value

Seems VS2010 doesn't support range based for loops.

😕 The problems are never-ending.

Anyway, this means it has to be VS2013+. The README needs an update. I'll try downloading an older version of the VS2013 installer.

[CyberShadow]

Sorry, I'm afraid I can't help you there. I agree that it's a mess, but it's mainly Microsoft's fault. My only advice would be to try to reproduce the environment that the CI builds happen in, as it is the only environment where we have a guarantee that the build process works.