* Clarifying some common pitfalls for Visual Studio debugging
Two minor changes made to this page, to help other people avoid wasting their time:
1. The page says at the end that it should be possible to place a breakpoint and if the steps were followed properly it should just work, however the dev_buil paramter is not mentioned anywhere in the same page and I would not be able to complete the setup without help from @anvilfolk.
2. I spent a couple of minutes trying to understand why the debugger would not attach and instead would exit with code 255 - no errors or hints shown (like path not found, or could not parse, etc). Ended up being a simple mistake of having white spaces in the path. I think its worth mentioning in the docs.
Also updating the screenshot to suggest double quotation marks by default as safer alternative that can handle whitespaces.
---------
Co-authored-by: Max Hilbrunner <mhilbrunner@users.noreply.github.com>
- Simplify history section on SCons.
- Add a section on `production` and `dev_mode` aliases.
- Add a section on `debug_symbols` and `separate_debug_symbols`.
- Add a section on `optimize`.
The compiledb=yes flag is only documented in the vscode and clion sections, but is relevant to any LSP-based editor.
In addition, nothing mentioned the ability to generate a compilation database without compiling, referenced here:
https://github.com/godotengine/godot/issues/39883#issuecomment-924423857
The Introduction to the buildsystem page still mentions this parameter
in case it needs to be changed, but in most situations, the default
value of `(number of CPU threads) - 1` does a good job.
- Merge Community/Contributing and Engine Development into one top-level section, Contributing.
- Structure it in a way that gives equal priority to various ways to contribute, including documentation.
- Rename several articles to be more comprehensive and in line with the overall state of the documentation.
- Rewrite the guide for class reference contributions.
