Refactor support for multiple Meson projects

[xclaesse]

There were many issues, including:

• The most common case is to have a meson.build at the root of the workspace. In that case we should not ask user anything.
• Only the first meson.build in a subdir tree is useful, others are unlikely to be projects.
• We need a way to never ask again to select a meson file, especially important when opening meson project itself which does not have a meson.build at the root, but many projects in test cases.
• If the user cancels selection, the meson extension cannot do anything and should be hidden.
• Selecting a meson file and configuring the project are 2 distinct questions. The user may want to select a file but not let vscode configure it. It is common to configure from an external terminal.

[xclaesse]

CC @tristan957 @wolfpld. Could you please test this PR with your multiple projects case?

[tristan957]

I'll probably take a look Saturday or Sunday. Does the current situation with 1.18.1 work for you?

[wolfpld]

I think we have some significant communication issues here.

This is the first time you mention having a build dir preconfigured before opening the workspace in VS Code. Only now can I see what your comments about preferring a root-level meson.build really meant. To me, the sort order of the initial list was irrelevant, as it was sorted later when it was to be shown to the user. Yes, your use case is important to preserve, and it was not properly handled by my changes, but instead of properly describing what the problem was, you chose to hasten the changes, resulting in a rushed #190, as can be seen by reading your own post-merge comments there. The alternative I presented, which by the way was waiting half a day, would give you the inconvenience of having to choose the default option from a list once. Sorry, but I don't see that as a major deal breaker.

Nota bene, if we are talking about breaking workflows, the workflow in which you select to configure the workspace, in the very dialog you are refactoring in this PR, has been broken for half a year, since May, and no one noticed.

Regarding your question, I don't know how these changes affect me. Because of the communication problems I do not know where the development is going. I asked some questions in the PRs yesterday and I am still waiting for your answer. At this point, I don't know if I want to continue putting time and effort into contributing to this repository, or if I should just fork, do what I need for my use case, and rely on that instead.

Ultimately, as @tristan957 said, you "definitely need more contributors to this extension". It's up to you how you want to handle that.

[xclaesse]

@wolfpld sorry if it wasn't clear what was broken, it seemed pretty obvious to me since just opening any project results in the mentioned problems.

In any case, this PR fixes tones of things, not all related to multi projects repository, so I think it would be a good improvements anyway.

[wolfpld]

I think it would be a good improvements anyway.

I agree.

• The most common case is to have a meson.build at the root of the workspace. In that case we should not ask user anything.
• Only the first meson.build in a subdir tree is useful, others are unlikely to be projects.

I wouldn't say that my use cases support these statements, but at this point it doesn't matter. There are things that need to be ironed out in my implementation and your proposed solution fixes most of the pressing issues (albeit not in an ideal way from my point of view).

• We need a way to never ask again to select a meson file, especially important when opening meson project itself which does not have a meson.build at the root, but many projects in test cases.
• If the user cancels selection, the meson extension cannot do anything and should be hidden.

As mentioned earlier, this was the result of a well-intentioned change (if a === true => if a) where the variable type was not just boolean. This flew under the radar and broke the dialog.

Selecting a meson file and configuring the project are 2 distinct questions. The user may want to select a file but not let vscode configure it. It is common to configure from an external terminal.

Would that be to set things such as build type, or such? Maybe this should be exposed in the GUI somehow?

[wolfpld]

Some relevant notes about the internal implementation of VS Code mementos:

The memento data is stored in %APPDATA%/Code/User/workspaceStorage/<workspace hash>/state.vscdb. The workspace.json file in the same directory allows to identify which workspace it is.

The state.vscdb file is a sqlite database with ItemTable as the only table. This table has two columns: key, a unique text, and value, a blob.

All mementos used by this extension are stored in a row with the key mesonbuild.mesonbuild. The value column stores a json data with key-value pairs as specified in the code.

sqlite> select value from ItemTable where key='mesonbuild.mesonbuild';
{"mesonbuild.buildDir":"/home/wolf/meson-test-repo-multi/a/b/c/d/e/build","mesonbuild.sourceDir":"/home/wolf/meson-test-repo-multi/a/b/c/d/e","mesonbuild.mesonFile":"/home/wolf/meson-test-repo-multi/a/b/c/d/e/meson.build"}

The memento state can be reset with the following command: delete from ItemTable where key='mesonbuild.mesonbuild';.

[tristan957]

You left a merge conflict in

[tristan957]

It would also be great to get some of this split out into separate commits. Some of the changes seem unrelated to multiple meson projects. I like the refactoring you did with dialogs.ts

[xclaesse]

You left a merge conflict in

Fixed.

It would also be great to get some of this split out into separate commits.

done.

[wolfpld]

I found a problem that was probably always present in the code, but is now better exposed.

Assuming you have selected a project root, if the "Meson project detected in this workspace but does not seem to be configured..." dialog appears and you click the "no" button or the "x" close button, the project is not configured and the extension continues to work as expected. For example, you can "select project root directory" and it will work.

However, if you close the initial dialog with the Esc key instead, the extension will not respond. No command (e.g. "select root dir" or "reconfigure") will work in this case.

---

Another problem: When the "select project root directory" command is selected (but not when it is displayed in response to the "multiple meson projects detected..." dialog) and you click outside the selection popup, the popup closes and the VS Code window reloads, and the "multiple meson projects detected..." dialog reappears, even if you have already made this selection.

[xclaesse]

However, if you close the initial dialog with the Esc key instead, the extension will not respond. No command (e.g. "select root dir" or "reconfigure") will work in this case.

I think this is how vscode is expected to work... microsoft/vscode#62853. Pressing escape hide that notification, but it's still running. In our code that means we are still awaiting for the response.

When the "select project root directory" command is selected (but not when it is displayed in response to the "multiple meson projects detected..." dialog) and you click outside the selection popup, the popup closes and the VS Code window reloads, and the "multiple meson projects detected..." dialog reappears, even if you have already made this selection.

Right, if selectRootDir() returns undefined we should consider the user cancelled the request and keep using current sourceDir. But we probably should add a special value in the dropdown menu to select "no meson project". For now I updated this PR to not update when it returns undefined.

[xclaesse]

@tristan957 I think we should merge and release with this PR. Any objection?

[tristan957]

Just some nit picks, then let's merge it and tag a release tomorrow.

[xclaesse]

Rebased and it uses @tristan957's sorting algo. Good to go?