Add support for vscode #92

jonnysoe · 2023-03-11T18:04:51Z

No description provided.

GitMensch

Thank you for taking the time to document this. Please move the docs to a separate "vscode" folder, following the current docs structure.

Furthermore I do have concerns related to the proprietary extensions used, and I won't pull it myself as long as those are used. Lexxmark may see this different.

GitMensch · 2023-03-12T12:08:28Z

.vscode/extensions.json

+
+    // List of extensions which should be recommended for users of this workspace.
+    "recommendations": [
+        "ms-vscode.cpptools-extension-pack",        // Comes with CMake for Debugging C++


I personally won't recommend those proprietary extensions (only daohong-emilio.yash is free to use), which hinders me to pull this. Please drop all but yash (I wasn't even aware of it, thanks for sharing!) and consider adding cmake specific extension.

I'll limit this to ms-vscode.cmake-tools, this alone is minimal and enough for normal use case

GitMensch · 2023-03-12T12:09:57Z

.vscode/launch.json

+            // https://code.visualstudio.com/docs/cpp/config-msvc
+            // https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
+            "name": "(windbg) Launch",
+            "type": "cppvsdbg",


similar, this one is sadly not free; you may want to use clangd for intellisense and native-debug for debugging when you want to add those to the repo

This is the launcher for debugger, it has nothing to do with clangd as it is the language server for code navigation, and I'll leave clangd out since its interfering with IntelliSense, may cause problems for others too, IntelliSense will be removed from the workspace recommended extensions.json.

The debugger may be problematic, I'm not entirely sure about the free licensing you're referring to or what native-debug is, however this is the only debugger for MSVC which is what we're using, its not entirely WinDbg per se, but the same free proprietary tools Windows SDK bundles - Debugging TOols for Windows, WinDbg, CDB, KD, NTSD...

On a side note, did you mean open source? Please clarify

@GitMensch ,
is your "free" referring to free-as-in-speech (libre)? WinDbg is part of Windows SDK which is free-as-in-beer (gratis), but its the only debugger for MSVC, its just configuration and we are not even redistributing this to users or developers

This is about the extension necessary - the cppvsdbg debug type is only part of a Microsoft extension that can only be used with Visual Studio Code, so "free beer if you sit only on a specific chair with no single adjustment, that comes pre-configured to tell the maker whenever you sit on it" (and the beer likely doing the same); and with the adjusted recommendations we don't have that available any more, I think. Am I wrong?

Note: If I remember correctly you can use LLDB to debug msvc generated modules, too - for this setup there are some free extensions (like "free to use for anything, anywhere, including adjusting the extension and re-distribute it"- "libre"), too.

Nope, its a known issue which is why its never published in the vscode documentation, it may be possible in the CLI/TUI but LLDB cannot be used to debug MSVC-generated symbols in vscode as it lacks LLDB-MI for non-Apple platforms at the moment, the closest LLDB for vscode is the CodeLLDB extension which is not compatible with MSVC-based symbols; not even MSVC-based Clang programs, MSVC-based Clang programs will still need to use WinDbg since its PDB symbols are MSVC-based...
Getting LLDB-MI to work on Windows will require quite some effort from the community, which is inactive at the moment...

Yes, the recommended beer will be gone from the recommended extensions, I think having this debug configuration is not as evil as telling devs "the free beer is required or recommended", for now the codebase is only compatible with this beer (MSVC), if you need to debug, this is the only available beer (which we did not bundle) at the moment 🙊

P.S. I can try to get the codebase compatible with WinLibs/UCRT after this, just not within this PR as it requires quite some changes

C strings will definitely work, STLs don't, since upstream are GNU guys and they don't like C++ or STLs, I can accept codeLLDB without being able to debug std::string and std::vector in this workspace, I'll default this to codeLLDB

LLDB folks are GNU guys?
GNU guys don't like C++or STLs (just have a look what some of the GNU software is written in...)?

Note: for GDB you commonly want pretty-print handlers for C++ and STL types, maybe this is similar with LLDB?

fair warning: I'm a GNU guy and when I (seldom) do C++ or STL it is in other people's code

The debugger may be problematic, I'm not entirely sure about the free licensing you're referring to

the microsoft extension is not free, as you can see in its license

You may install and use any number of copies of the software only with Microsoft [...] Visual Studio Code

--> this explicit disallows use with any other built of vscode repo and the extension also checks for the Microsoft identifiers in product.json, so disables itself when it "believes" it is not run on the "single blessed binary product"... and they even have a wiki page explaining that: https://github.com/microsoft/vscode-cpptools/wiki/Microsoft-Native-Debugger-licensing-and-Microsoft-Visual-Studio-Code

or what native-debug is

It is one of the extensions that can work with lldb-mi, so if you have a binary lldb-mi, then you can use it.

however this is the only debugger for MSVC which is what we're using,

No, as noted you can use the lldb extension which distributes windows binaries, too (but not lldb-mi) to debug MSVC generated binaries as well as any debug extension that supports lldb-mi.

My point was exactly that I don't this repo to suggest people to use the non-free extension (that will only work on "MS' blessed binaries, so for example not any of my vscode installations)and let all others have a note in their problems pane that the debug type is unsupported.

Thank you so much for going above and beyond to clarify, now I understood what you meant, it is free if user/dev is on MS tool suites, not free for any other variants or forks of Code - OSS
TL;DR the rule for this free beer is MS binaries

TL;DR the rule for this free beer is MS binaries

yes, along with binaries where the code is explicit not released - and both have an explicit opt-out of telemetry (which you can set, but as the sources are closed you can only check what goes out by firewall [blocking some of that works, others broke the extension, but that's a too unrelated thing to this PR and I also have no recent data about that, so "ignore that part of my rant, please - just keep in mind 'nobody but MS can actually check what the software does'"]).

GitMensch · 2023-03-12T12:10:57Z

.vscode/settings.json

@@ -0,0 +1,10 @@
+{


It seems those settings would best be user-scope, not specific to this workspace.
Please share your reasoning if your disagree.

Workspace is the appropriate place for codebase consistency settings, unless that is something we don't want...

First is editor settings, most users have different settings which will make the codebase inconsistent, the proper way to have consistent code is clang-format, but that will format the whole code instead being just limited to the addtional lines introduced by developers; and will probably make it more difficult to sync with upstream.
Trailing whitespace is undesirable, for consistency and nothing much to explain further

Ruler indicator is just a mindful/useful indicator, I see GNU have an unwritten rule of 80 character line limit, but some codes go up to 120 chars in flex/bison, I'll say this is optional, I can remove this if you don't like to see these lines

The git operations are minimal and good to have for new developers, it helps to ensure git pull in vscode don't branch and merge, prune is optional as it helps to cleanup deleted branches in origin just that the code base is not super active at the moment

CMake preferred generator won't mess up the system as it only uses Ninja if its installed, although the codebase is small, it approximately halves the compilation time for debugging

GitMensch · 2023-03-12T12:14:22Z

README.md


 ## HowTo
 You may use win_flex and win_bison directly on the command line or [use them via CustomBuildRules in VisualStudio](custom_build_rules/README.md).
+### Visual Studio Code


Following the current README's and repo structure this file and images should be moved out to a separate vscode folder, linked here as done for the CustomBuildRules.
Please also consider using "vscode" instead, because there are more binary packages then the one distributed by Microsoft.

I'll try to mirror that directory...

GitMensch · 2023-03-12T12:15:23Z

README.md

@@ -8,7 +8,7 @@ Both win_flex and win_bison are based on upstream sources but depend on system l
 * 2.5.x versions include GNU Bison version 3.x.x

 ## License
-Flex uses a [BSD license](flex/src/COPYING), GNU Bison is [licensed under the GNU General Public License (GPLv3+)](bison/src/COPYING).  
+Flex uses a [BSD license](flex/src/COPYING), GNU Bison is [licensed under the GNU General Public License (GPLv3+)](bison/src/COPYING).


.md files should not be whitespace-trimmed at the end. Those two trailing spaces lead to a line break, otherwise it would be a block text, please revert this part.

Its trimmed by trimTrailingWhitespace, I'll reinsert them and add md files as exception

GitMensch · 2023-03-12T12:19:13Z

README.md

@@ -25,10 +25,37 @@ The release page includes the full Changelog but you may also see the [changelog

 ## Build requirements
 * Visual Studio 2017 or newer


We should change that to say "... build tools" (which is a separate package, for example pre-installed in several CI environments) or specify builds; this is not related to this PR but could be done together.

The pre-installed build tools I see in AppVeyor are all VS...
What does "... build tools" mean? Does that mean "Visual Studio 2017 or newer build tools"?
Or you you wanted something different like the following?

C++ build tools (MS BuildTools, Visual Studio 2017 or newer)

I mean - you don't need the full Visual Studio installed, the Build Tools for C++ (which are included in Visual Studio) are enough.

Alright, its the latter, I'll update it 👌

GitMensch · 2023-03-12T12:21:24Z

README.md

+            ],
+```
+
+6. Setup the IDE for inspection [debugging](https://code.visualstudio.com/docs/editor/debugging), eg. breakpoints, logpoints.


it likely is more reasonable to not use "IDE" here; not sure if "editor" as used in the vscode docs is the best option, but it would be better.

Wording/spacing/punctuation: "Set up" and "e.g. breakpoints or logpoints."

How about calling it "codebase"? It'll be vague but indicative

I'm fine with that.

Add support for vscode

b79c50f

GitMensch requested changes Mar 12, 2023

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for vscode #92

Add support for vscode #92

jonnysoe commented Mar 11, 2023

GitMensch left a comment

GitMensch Mar 12, 2023

jonnysoe Mar 13, 2023

GitMensch Mar 12, 2023

jonnysoe Mar 13, 2023

jonnysoe Mar 14, 2023

GitMensch Mar 14, 2023

jonnysoe Mar 14, 2023

jonnysoe Mar 15, 2023

GitMensch Mar 15, 2023 •

edited

GitMensch Mar 15, 2023

jonnysoe Mar 16, 2023

GitMensch Mar 16, 2023

GitMensch Mar 12, 2023

jonnysoe Mar 13, 2023

GitMensch Mar 12, 2023

jonnysoe Mar 13, 2023

GitMensch Mar 12, 2023

jonnysoe Mar 13, 2023

GitMensch Mar 12, 2023

jonnysoe Mar 13, 2023

GitMensch Mar 13, 2023

jonnysoe Mar 13, 2023

GitMensch Mar 12, 2023

jonnysoe Mar 13, 2023

GitMensch Mar 13, 2023

		@@ -25,10 +25,37 @@ The release page includes the full Changelog but you may also see the [changelog

		## Build requirements
		* Visual Studio 2017 or newer

Add support for vscode #92

Are you sure you want to change the base?

Add support for vscode #92

Conversation

jonnysoe commented Mar 11, 2023

GitMensch left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GitMensch Mar 15, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GitMensch Mar 15, 2023 •

edited