Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes when there are spaces in test target name #47

Merged
merged 11 commits into from
Nov 20, 2021

Conversation

lukester1975
Copy link
Contributor

Hi

Great that this extension is now part of the meson project and will hopefully get some love.

Here are some patches to fix a few issues with spaces in test target names and to use meson rather than ninja for all commands (I use samurai).

I other less trivial ones but thought I'd see if these are of interest first.

Regards

Copy link
Member

@dcbaker dcbaker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this! I have one question, but otherwise this looks good to me

const title = name ? `Building target ${name}` : "Building project";

getOutputChannel().append(`\n${title}\n`);
const stream = execStream(`meson compile ${name ?? ""}`, { cwd: buildDir });
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this be quoted too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd only done test targets as surely nobody puts spaces in binary names 😀

That said, the one you reference ends up spawning and not going via the shell:

export function execStream(
command: string | string[],
options: cp.SpawnOptions
) {
//FIXME: Force string array and fix callers
if (typeof command === "string") {
command = command.split(" ");
}
const spawned = cp.spawn(command[0], command.slice(1), options);

So quoting breaks it there. The FIXME would solve the problem I suppose, though I get the feeling from looking at the code some greater refactoring to tidy up the multiple routes things can take is the right solution...

I'll update the PR for one other compile command that is going via the shell for now.

@lukester1975
Copy link
Contributor Author

Actually scratch that. Thought I'd better check what Windows does (well, Powershell) and it is pretty horrible.

That said, looks like ShellQuoting might come to the rescue.

@lukester1975 lukester1975 marked this pull request as draft November 18, 2021 15:34
* typescript 2.4.1 -> 4.4.4
* vscode 1.1.34 -> 1.1.37
* types/node 12.0.2 -> 16.11.7
@lukester1975
Copy link
Contributor Author

OK here's a revised work in progress that works with powershell. Still draft as there's a few things I need to look at, but any feedback welcome in the meantime!

The main fix was switching from ShellExecution -> ProcessExecution to just avoid any shell escaping issues. No variable expansion was required in the places I've made that change, AFAICT, so should be safe.

#47 (comment) is also done now.

TODO:

  1. Seemed reasonable to be consistent and use ProcessExecution everywhere, but there are 2 ShellExecutions left that I need to investigate to ensure no breakage.
  2. Haven't removed exec() calls, which are also going via the shell. Probably a separate PR as not related to the actual issue, really.
  3. Building a target in a sub-directory doesn't work on Windows... but that's nothing to do with these changes (current main branch doesn't work either). Looks to me like meson itself doesn't like backslashes in the target name. I'll try to take since I'm in that area.

Cheers

@lukester1975 lukester1975 force-pushed the fix-spaces-in-target-name branch 2 times, most recently from 999b67e to b48d540 Compare November 18, 2021 20:53
Meson requires the separator between path and target name to be '/'.

ALso, since the full target name can now end up as "path\to/targetName", don't show path\to in the tree view
(it's implicit from the nodes anyway).
Don't do that.
Also removed unused exec() function.
…ate command/args parameters.

Will allow spaces in target names to work cross-platform (avoiding shell escaping issues).
No uses require shell variable expansion, etc.
I.e. Meson -> Run Unit Tests -> all, or specific test name with spaces.
Uses ProcessExecution rather than ShellExecution for ninja/meson invocation to
avoid shell space escaping issues. No uses require variable expansion, etc.
Samurai now works, via NINJA=samu.
@lukester1975
Copy link
Contributor Author

OK here's a "final" version I'm happy with, with one caveat:

2. Haven't removed `exec()` calls, which are also going via the shell. Probably a separate PR as not related to the actual issue, really.

I did this in 84a3be0. But I could see an issue - if someone's used a shell variable in their configure options, then previously it would've been expanded but now won't be. Would be nice if there was an API to support vscode variable expansion and use that (e.g. microsoft/vscode#46471) but I guess not. So maybe this commit should be binned? There's no real downside (aside from being nice to consistently avoid the shell) unless someone has spaces in their build dir, AFAICT...

3. Building a target in a sub-directory doesn't work on Windows... but that's nothing to do with these changes (current main branch doesn't work either). Looks to me like `meson` itself doesn't like backslashes in the target name. I'll try to take since I'm in that area.

That was a pretty trivial fix. Meson seems to be happy as long as the separator between dir and target name is a forward slash.

Hope it's useful. Makes the extension usable for me anyway!

I've got a few more other fixes but unrelated, so might as well get this in first.

@lukester1975 lukester1975 marked this pull request as ready for review November 19, 2021 15:35
@dcbaker
Copy link
Member

dcbaker commented Nov 19, 2021

Would that also prevent shell variables that meson interpreters internally stop working? I do rely on that (PKG_CONFIG_PATH, in particular)

@lukester1975
Copy link
Contributor Author

Which bit in particular do you mean? The avoiding of the shell when running meson commands in general or the specific case I mention in 84a3be0?

For 84a3be0, what I'm saying is if you had say mesonbuild.configureOptions = [ "${SOME_VARIABLE}" ] (or in whatever format appropriate for your shell, I suppose) then there would be no expansion of ${SOME_VARIABLE} by the shell (as there isn't one) before invoking meson. I.e. it would literally receive ${SOME_VARIABLE} as a command line argument rather than its value.

It's the only case in the extension I could see where there might be an issue. All the other uses are just meson <command> [--maybe a switch] maybe a target name].

For the first case - whatever environment VSCode has will be inherited by the meson it runs, it's just that there's no longer a shell process in the middle. So wherever meson is doing env['PKG_CONFIG_PATH'] should get the same result.

HTH!

@dcbaker
Copy link
Member

dcbaker commented Nov 20, 2021

Yeah, that should be fine. I use nix, so having environment variables is pretty important for things to work, lol

@dcbaker dcbaker merged commit fbd4fb6 into mesonbuild:main Nov 20, 2021
@lukester1975 lukester1975 deleted the fix-spaces-in-target-name branch November 20, 2021 11:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants