mesonbuild / vscode-meson

Meson for VisualStudio Code
Apache License 2.0
107 stars 50 forks source link

Executable targets fail on windows #13

Open Salamandar opened 4 years ago

Salamandar commented 4 years ago

I'm using Meson on MingW. Configure fails, but once it's configured in the Mingw shell, targets build works. But not for executables.

The extension tries (i.e) src\executable, so I get ninja: error: unknown target 'src\executable'.

It should try src\executable.exe.

Salamandar commented 4 years ago

I found where the issue is. And the problem is not only for executables on windows, but also for custom targets (mergefmt, gnome targets,…). In utils.ts, you need to change getTargetName() with:

export async function getTargetName(t: Target) {
  const buildDir = workspaceRelative(extensionConfiguration("buildFolder"));
  const buildOptions = await getMesonBuildOptions(buildDir);
  const layoutOption = buildOptions.filter(o => o.name === "layout")[0];
  var filename = path.parse(t.filename[0]).base;
  if (layoutOption.value === "mirror")
    return path.join(
      path.relative(vscode.workspace.rootPath, path.dirname(t.defined_in)),
      filename
    );
  else return `meson-out/${filename}`;
}

Looks file run targets are also broken, so you need to check like:

export async function getTargetName(t: Target) {
  const buildDir = workspaceRelative(extensionConfiguration("buildFolder"));
  const buildOptions = await getMesonBuildOptions(buildDir);
  const layoutOption = buildOptions.filter(o => o.name === "layout")[0];
  if (t.type == "run") {
    return t.name;
  } else {
    var filename = path.parse(t.filename[0]).base;
    if (layoutOption.value === "mirror")
      return path.join(
        path.relative(vscode.workspace.rootPath, path.dirname(t.defined_in)),
        filename
      );
    else return `meson-out/${filename}`;
  }
}
dresch86 commented 4 years ago

@Salamandar I realize I am a bit late to the party, but I started working on a fork several months back that focuses on improvements for MinGW handling. The problem now is that the plugin gets confused syntactically as its not consistently distinguishing between the different environments. Now that I have time to resume the work I was doing it may be of help to you. I am not sure if the maintainer of this package still has use for it. I opened an issue awhile back too and haven't heard anything yet.

asabil commented 4 years ago

Hi @dresch86 @Salamandar I am currently unable to look into fixing this, however I would be happy to merge any PR that solves this.

Ongy commented 2 years ago

Since everything was switched to meson instead of using ninja in 318c1df82f7eedfc6456719e711276d95b1d7242 this shouldn't be an issue anymore.

Can you please re-test. Maybe also @dresch86. I don't have a windows setup to test.

MightyPork commented 3 months ago

I'm on linux and maybe this is the same bug, but honestly I'm not sure as I'm new to both meson and vscode.

The definition looks like this:


bl_exe = executable(
  'vester-bl',
  bl_src,
  name_suffix : 'elf',
  dependencies : bl_deps,
  include_directories : bl_inc,
  link_args : bl_link_args,
  link_depends : bl_link_depends,
  c_args : bl_c_args,
)

The extension tries to execute:

meson compile vester-bl:executable

this fails:

INFO: autodetecting backend as ninja

ERROR: Can't invoke target `vester-bl:executable`: target not found

If I go to the build directory and run meson compile vester-bl in terminal, that works. It also works with vester-bl.elf. vester-bl:executable fails even when run manually.

ftr it's cross-compilation with a custom cross file, meson 1.4.1