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

xmake fails on Windows when path contains parentheses #119

Open
danielpieczko opened this issue Nov 28, 2023 · 2 comments
Open

xmake fails on Windows when path contains parentheses #119

danielpieczko opened this issue Nov 28, 2023 · 2 comments

Comments

@danielpieczko
Copy link
Collaborator

Seen by a user on xcore.com: https://www.xcore.com/viewtopic.php?p=40452#p40452

I've reproduced this on Windows. Our CI tests use get_tools so we aren't testing from the default Windows install location.

The solution may be to use cmake_path in the toolchain file to create a properly escaped path to the tools.

@danielpieczko
Copy link
Collaborator Author

From my testing, this happens when using a bash shell on Windows (eg. via Git BASH) when the XTC Tools are installed into the default location C:\Program Files (x86)\XMOS

This table shows the results of building sw_usb_audio with xcommon_cmake and xcommon. CMD is the XTC Tools CMD prompt (installed in the default location); BASH is Git BASH loaded from the XTC Tools CMD prompt, so that the environment variables are exported inside the BASH shell.

     | xcommon_cmake | xcommon
-----+---------------+----------
CMD  |    works      |  works
BASH |    fails      |  works

Summary:

  1. xcommon_cmake doesn't work in Git BASH on Windows when the XTC Tools are installed in the default installation directory
  2. a workaround is to install the XTC Tools in a different directory (containing no symbols)
  3. xcommon doesn't suffer in the same way as xcommon_cmake
  4. on Linux and MacOS, xcommon_cmake works with symbols in the path to the XTC Tools, but xcommon fails with an error like this one!

@danielpieczko
Copy link
Collaborator Author

This is an issue in Make itself rather than anything we've done with xcommon_cmake.

When Make runs, it sets a Makefile variable called MAKE which is a path to the executable that was run. If the MAKE variable contains a symbol like a parenthesis, Git BASH will raise an error when that variable is used in a Makefile.

If you've written your own Makefile, you probably haven't used $(MAKE) so this problem doesn't appear, and so doesn't apply to anything in xcommon. But CMake-generated Makefiles use $(MAKE) throughout, so this is why we see this issue with xcommon_cmake.

This behaviour is not unique to our tools: using GNU Make 4.4.1 with a simple Makefile containing $(MAKE), I can reproduce the same error in Git BASH. I've tried different combinations of quoting and escaping special characters in paths, but I can't find anything that works.

There is an ugly workaround: since MAKE is a Makefile variable, you can set it on the command line. In this way, you can change what executable is used if $(MAKE) is invoked from your Makefile. Since the path with a symbol is the problem, the variable can be set just to the binary name, and then invokations in the Makefile will have to be resolved from the PATH environment rather than immediately running from the full path location. Result: running xmake MAKE=xmake solves this problem and the xcommon_cmake build then works in Git BASH.

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

No branches or pull requests

1 participant