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

Handling of cmd.exe in VS2017 vs. VSCode? #330

Closed
doingnz opened this issue Sep 9, 2018 · 4 comments
Closed

Handling of cmd.exe in VS2017 vs. VSCode? #330

doingnz opened this issue Sep 9, 2018 · 4 comments
Labels

Comments

@doingnz
Copy link

doingnz commented Sep 9, 2018

  • A brief description
    I am trying to add support for nanoFramework to use these tools to cross compile to embedded systems, starting with Espressif ESP32.

CMake/Ninja generate build.ninja and rules.ninja under VSCode and VS2017 (15.8.x) that are the same. VSCode will successfully build the project to completion. VS2017 compiles all the src files, but fails near the end of the build process when it needs to launch cmd.exe, saying it cannot find cmd.exe.

If I edit build.ninja and rules.ninja and replace 'cmd.exe' with C:\WINDOWS\system32\cmd.exe, then the build will succeed. This works until the two files get auto regenerated.

  • Expected results
    rules.ninja and 'cmd.exe' should have ${env.COMSPEC} as the shell command exe, or there should be a way to set this via settings to C:\WINDOWS\system32\cmd.exe (or whatever is suitable to a system.

  • Actual results (with build output window contents if applicable)

#############################################
# Utility command for edit_cache

build CMakeFiles/edit_cache.util: CUSTOM_COMMAND
  COMMAND = cmd.exe /C "cd /D C:\Projects\nf\nf-interpreter\build && "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake-gui.exe" -HC:\Projects\nf\nf-interpreter -BC:\Projects\nf\nf-interpreter\build"
  DESC = Running CMake cache editor...
  pool = console
  restat = 1
build edit_cache: phony CMakeFiles/edit_cache.util

#############################################
  • VC++ version, Linux system name and version, GCC/GDB/gdbserver version, CPU arch, etc. If you are using a specific version of Linux on an embedded board, we might need to know about it to get a repro on similar hardware

  • Steps required to reproduce the error

checkout the vs2017 branch from here: https://github.com/doingnz/nf-interpreter

Branch vs2017 has two additional files compared to the main repo develop branch.
• CMakeSettings.json
• CppProperties.json

run the power shell script `.\install-tools.ps1 -BOARD_NAME ESP32_DEVKITC -COMPORT COM19' to fetch the tools for ESP32 into default locations. They are just copied into place, so you can delete them afterwards.

Open the project folder in VS2017 and build all.

I have spent several days trying to understand how the files build.ninja and rules.ninja are created and how to add a prefix path to the cmd.exe.

Please help. There will be many grateful people if we can get this to work.

@doingnz
Copy link
Author

doingnz commented Sep 9, 2018

I have made a custom build of CMake 3.12 (master) and then searched and replaced 'cmd.exe' with 'C:\Windows\System32\cmd.exe` and then every thing works as expected for nanoFramework builds under VS2017 with CMake.

The files that need to be updated:

Source\cmGlobalNinjaGenerator.cxx

#ifdef _WIN32
  if (cmd.empty())
    // TODO Shouldn't an empty command be handled by ninja?
    // cmd = "cmd.exe /c";
    // TODO: read environment variable 'COMSPEC' and use that if available.
    cmd = "C:\\WINDOWS\\system32\\cmd.exe /c";
#endif

Source\cmLocalNinjaGenerator.cxx

    if (li != cmdLines.begin()) {
      cmd << " && ";
    } else if (cmdLines.size() > 1) {
     // cmd << "cmd.exe /C \"";
    // TODO: read environment variable 'COMSPEC' and use that if available.
    cmd = "C:\\WINDOWS\\system32\\cmd.exe /C";
    }

Source\cmLocalUnixMakefileGenerator3.cxx

  if (this->IsWindowsShell()) {
    // makefileStream << "SHELL = cmd.exe\n"
    // TODO: read environment variable 'COMSPEC' and use that if available.
    makefileStream << "SHELL = C:\\WINDOWS\\system32\\cmd.exe\n"
                   << "\n";
  } else {

@doingnz
Copy link
Author

doingnz commented Sep 9, 2018

As an example, one can use something along the lines of:

#ifdef _WIN32
  if (cmd.empty())
    // TODO Shouldn't an empty command be handled by ninja?
      std::string cmdPath;
      try {
        if (!cmSystemTools::GetEnv("COMSPEC", cmdPath)) {
          cmdPath = cmSystemTools::FindProgram("cmd.exe");
        }
        if (cmdPath.empty()) {
          cmdPath = "cmd.exe";
        }
      } catch (...) {
        cmdPath = "cmd.exe";
      }
      cmd << cmdPath << " /C \"";
    }
#endif

The other three would be similar.

This tries to find COMSPEC environment variable. If that is not define, then search the PATH for cmd.exe. Otherwise just use cmd.exe, including in situations when an exception is thrown.

@lukka
Copy link
Member

lukka commented Sep 10, 2018

@doingnz I think you are cross compiling using the Windows's workload of CMake. If this is the case, could you please open a ticket on devcom ?

@lukka lukka closed this as completed Sep 10, 2018
@itodirel
Copy link
Member

We believe this scenario should be supported already, set the configuration as if you were targeting Windows.

We retired this issue list, here on Github. We now adopted and using the Developer Community (https://developercommunity.visualstudio.com/spaces/62/index.html), for Cross Plat and Linux experiences (and C++ all up generally), which we are actively monitoring. Please use the Developer Community, to report issues or suggestions for bugs or new experiences. Further discussions on this thread here on Github might be unmonitored. If there is further comments or context in this current issue, please create a new issue on the Developer Community and mention it there. For existing issues which we can reproduce, or anything that is actionable to us, we will provide an update right here, in this thread. For new suggestions or issues, which at this time are in our roadmap, or we believe and have evidence that it will broadly and/or significantly benefit everyone, we will open a suggestion ticket, with the issue or suggestion, and link it here. For anything else, we recommend to please open a ticket on the Developer Community.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants