• Cleanup pass & fill in missing bits of information.
• Merge remote-tracking branch 'origin/master' into tmp_crashlog
• clang-format
• move required libs to platform/platform_win32.cmake

Think the technical bits are ready for review, the html based submission wizard may need "some tweaks" though, perhaps have an actual webguy look at it (i'll be honest, 90% of the code/css is cut and pasted from w3schools in 20 minutes) adding @Dalai Felinto (dfelinto) as a reviewer to guide that into a direction we want.

Can there be a diff for just the part that makes it so we get a strack trace in the terminal or debug logs? That could be approved quickly.

And then a new one for the dialog and HTML based wizard?

I would like to have a wizard like this. But ideally it would be part of the bug submission form on developer.blender.org instead of embedded in Blender. So that we can keep updating it and don't need to add a bunch of custom CSS.

Yes the submission bit is already behind a cmake switch, we could easily take that to a different diff.

that being said, the change is big enough to be uncomfortable to be landing it in 2.83 still, 2.90 seems like the right place for this.

In general I'm not so convinced that submitting a back-trace to the tracker is all that useful.

There is some risk users will submit this thinking they have reported an issue, when we really need ways to redo the bug.

Having said that, the code-changes seem OK, but would rather backtrace support be split out from the HTML submission stuff (as @Brecht Van Lommel (brecht) mentions).

In D7520#181923, @Campbell Barton (campbellbarton) wrote:

In general I'm not so convinced that submitting a back-trace to the tracker is all that useful.

Getting the user to report basic information like blender version or system_info.txt on the tracker at times is a struggle, anything we can automate in this department imho is an improvement for the people triaging the tracker.

There is some risk users will submit this thinking they have reported an issue, when we really need ways to redo the bug.

True but we could deal with that in the html wizard, while the tracker has a big textbox people mostly ignore, we can actively stop the wizard from progressing unless they give an answer to certain questions (as the wizard currently does for the repro steps)

However given this functionality is about to be axed, lets put a pin in this conversation and continue when this gets its own review.

some issues popped up during final testing when building with ninja, while i sort this out, when landing can i change the default for WITH_WINDOWS_PDB to On ?

I guess we would enable this by default for all builds except releases? I think that is reasonable.

Then we'd need something like this:

diff --git a/build_files/buildbot/slave_compile.py b/build_files/buildbot/slave_compile.py
index 65cadea..ddb059e1 100644
--- a/build_files/buildbot/slave_compile.py
+++ b/build_files/buildbot/slave_compile.py
@@ -37,6 +37,10 @@ def get_cmake_options(builder):
     elif builder.platform == 'win':
         options.extend(['-G', 'Visual Studio 15 2017 Win64'])
         options.extend(['-DPOSTINSTALL_SCRIPT:PATH=' + post_install_script])
+
+        info = buildbot_utils.VersionInfo(builder)
+        if info.version_cycle == 'release':
+            options.append('-DWITH_WINDOWS_PDB=OFF')
     elif builder.platform == 'linux':
         config_file = "build_files/buildbot/config/blender_linux.cmake"

We could consider enabling it for official releases as well, I'm not sure.

Traceback (most recent call last):
  File "../blender.git/build_files/buildbot/slave_compile.py", line 119, in <module>
  File "../blender.git/build_files/buildbot/slave_compile.py", line 89, in cmake_configure
  File "../blender.git/build_files/buildbot/slave_compile.py", line 41, in get_cmake_options
  File "C:\b\win64_cmake_vs2017\win64_cmake_vs2017\blender.git\build_files\buildbot\buildbot_utils.py", line 85, in __init__
    self.hash = self._parse_header_file(buildinfo_h, 'BUILD_HASH')[1:-1]
  File "C:\b\win64_cmake_vs2017\win64_cmake_vs2017\blender.git\build_files\buildbot\buildbot_utils.py", line 107, in _parse_header_file
    with open(filename, "r") as file:
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\b\\win64_cmake_vs2017\\win64_cmake_vs2017\\build\\win64_cmake_vs2017\\source\\creator\\buildinfo.h'

the buildbot did not enjoy this, not obvious at first sight why the build path has win64_cmake_vs2017 in there 3 times, i reverted this change for now.

@Brecht Van Lommel (brecht) / @Sergey Sharybin (sergey) either of you willing to take a look ? (or if we go, we'll keep it for release that's fine with me)

Allright got that sorted out, I'll have another go at landing this tomorrow, end of the day here, and i want to be available in case all hell breaks lose again.

while this is stalled: what's the plan for release builds? personally i'd say we see how well this functions in the daily, and push the problem forward towards the release of 2.90 to decide if we ship with or without it.

Ok, we can postpone the decision of including this in releases, and just always enable it for now.