The C++ extension seems not able to recognise the toolchain installed via xpm #28
Comments
|
@nicreuss, I suspect the problem to be caused by VS Code not being able to start the applications via the In other words, the program referred in I will investigate during the next days, but if a patch in the C++ extension is needed, it'll take some time. |
|
I share your suspicions. The error seems to occur when the C/C++ extension queries the compiler. With the following configuration in c_cpp_properties.json The C/C++ extension debug log gives: |
|
Thank you for investigating. The solution in these cases is to start the executable via a sub-shell, like If you know some magic setting in VS Code to do this, it would be useful. The more elaborate solution requires a patch in the C/C++ extension and a test, if the command exists and is an I don't know the workflow for submitting patches to VS Code; first I have to find a solution and then to figure out how to send a pull request. |
|
Another alternate solution would be to create symlinks for files, as on Linux/macOS. This requires enabling developer mode, and works only on recent Windows 10 and newer. I avoided doing so for now, because the idea to have to enable a developer mode is kind of stupid, but in some cases it might make sense. VS Code must be fixed anyway, but it might take some time. |
|
By explicitly including .cmd in the configuration, all IntelliSense errors disappear
This does not seem ideal for cross platform development. I will check if the configuration can be tailored to each platform. |
|
Ok, that's one step forward. Try to update the CMake configuration to make it write the extension. This is not ideal for cross platform development in general, but in this case it does not matter, since the file is generated in the build folder, which is not persistent, it is not committed in repos, and not moved to a different platform, it is simply regenerated on a new platforms. |
|
That is a very good point! Your suggestion solves the issue. I'm not well practiced with CMake but the code below seems to do the trick. if("${CMAKE_HOST_SYSTEM_NAME}" STREQUAL "Windows")
set(CMAKE_C_COMPILER "${CMAKE_C_COMPILER}.cmd")
set(CMAKE_CXX_COMPILER "${CMAKE_CXX_COMPILER}.cmd")
endif() |
|
CMake is not my thing either, but your code seems fine. Until a solution will be available, I'll update the template to use this workaround. |
|
Awesome! Thank you @ilg-ul for all your hard work on the xPack ecosystem. |
|
Thank you for your help to improve it! |
|
|
The workaround described above did not work for me (I will give details on that below). However, I have a different workaround. I added I've noticed that the xPack C/C++ Managed Build Tools extension will not interfere with the This form is cross-platform compatible. The symlink is now on the This is a non-ideal solution however as it requires adding Build from WSL2/Ubuntu 22.04: Would it be possible to modify the xPacks extension so that it sets |
|
As far as modifying the toolchain file to append If I set only If I try to set them explicitly, then they do not show up in CMakeCache.txt. This auto-detection scheme seems to choke when You can see that it attempted to find the |
I need to think about it, but at first sight I am not convinced that this is a generic solution. What is the criteria to decide on using that specific path? My projects use multiple toolchains, with different build configurations having their own toolchains, so there is no unique compiler path.
I'm not sure I understand this. For Windows, links are very tricky, links to folders are functional, but links to files are very problematic, thus the need for If you have a better idea on how to deal with them, please open separate topics in the Discussions section. |
Yes, unfortunately CMake is not happy with |
|
I can open a separate topic in the Discussions section, but I may not be able to get to it for a while. I think you're right that the compiler path would need to come from |
|
|
Yes,
On Windows, links to folders are called junctions, and are functional. Can you rephrase your proposal, and try to make it clearer? I probably have a bad day and I don't understand your point. |
|
@aaronf-at-d5, did you see a functional project using xpm for managing building and running unit tests? (https://github.com/micro-os-plus/utils-lists-xpack/blob/xpack/README-MAINTAINER.md#testing) |
|
Hi @ilg-ul, thank you for sharing that link. I will need some time to go over it. I'm fairly new to xPack. I've only been using it so far for a couple of weeks and only to manage dev environments. I may be posting on the wrong place here. I am still learning how all these pieces work together. If the xPack C/C++ Managed Build Tools extension shouldn't be populating As far as using junctions to link to another location in the system, this seems to work just fine. I decided to do an experiment to test this. Rather than run Note that I'm using a Makefile shim here as described in the Embedded Artistry CMake course, so In IntelliSense is working correctly with only the following in |
The xPack extension is invoking CMake to create the If this mechanism works properly, there is no need to set If this mechanism does not work properly, either CMake does not generate the correct On macOS I did not encounter such problems, so they might be Windows specific. BTW, setting the compiler path is not enough, for accurate IntelliSense you also need to configure the include paths, the defined macros and the compiler options. That's exactly the point why the xPack extension uses |
|
Hi @ilg-ul, please let me explain my motivation. I understand that the VS Code xPack extension is not working properly on Windows, specifically with regards to IntelliSense. I have been looking into this for a few days with the aim of finding a way to resolve or mitigate the issue. I know that it works correctly on Mac and Linux. That is my context for posting here.
Yes, I understand this. As I said in my previous post:
This is why I went on to conduct an experiment to see how Specifically, here is the difference: When using When performing the experiment I outlined above, it ends up with this path: Both work properly for building the project. The second is interpreted correctly by VS Code IntelliSense. What this implies is that rather than prepending
Yes, I understand this. That is the whole reason I've pivoted from my original idea of modifying |
This is not correct, it should end with |
|
If you generate the hello world project on Windows, using the template, as shown in the xCode extension README, does IntelliSense properly parse the |
|
After re-reading your message, I think I understood your proposal. You suggest that, on Windows, to no longer use This would introduce an inconsistency, probably even an incompatibility, between platforms, and an inconsistency with npm, which uses exactly the same I know that the .cmd mechanism has some issues, but I don't think it is unusable; I'll try to run some more tests on Windows, to validate this. Before further tests, please fix your tools to generate valid |
|
I think I understand what you're saying. You're saying to add the To make this still work cross-platform, I'd have to conditionally add the Thing is... I've never had to append anything. I just set And CMake just figures it out. Here is what happens running without a suffix on The question is, why does that continue to work when using So... does that work as a compile command? Yes, it does. Testing a single command out of the I tested the hello world project and the IntelliSense does appear to be working correctly. I'm not sure why I'm not seeing any complaints or VS Code reverting to |
No, it has nothing to do with using gcc, it has with having the correct file names. The issue has nothing to do with CMake, xPacks, GCC, etc, it is a limitation of the VS Code IntelliSense code, which, on Windows, is not able to start extension-less commands from This is just one of the many joys of using Windows. I guess VS Code can be fixed, but I had no time to further investigate and submit a pull request. |
|
Okay, I think I finally understand what you're saying. IntelliSense works as long as there's an extension on the compile commands in This makes sense to me. Windows has always used file extensions as opposed to file contents to identify file type. I don't see this as good or bad, just different. I think where my disconnect came in here is that I've been relying on CMake to add the extension. If I set Using this method with xPack doesn't work. It will compile, but the IntelliSense breaks. Why does it compile? I did some further digging and what I found is not intuitive. CMake tries to figure out the path and extension of the compiler. The existence of both However, the Windows CLI is adding There is a conflict here between how CMake and xpack are trying to manage cross-platform support on Windows. Adding the At this point I'm not sure any change should be made to xpack. I don't understand enough about npm or the motivation for the use of |
I would phrase it differently: IntelliSense parses
I personally highly dislike many of CMake 'automation' features, since they try to outsmart the user, and cause so much confusion. The former is a shell script required when npm/xpm are invoked from a shell in a mingw-like environment. There is not much we can do about it.
I think that both are workarounds conceived to overcome some of the many Windows limitations. I would not recommend messing with the PATH, I think that adding If you think that manually managing the path is ok for your projects, feel free to use it, but maintaining the projects will not be easy. Take a look at a complex project package.json, with multiple dependencies, and try to replicate the functionality without |
|
Thank you for the feedback and perspective. Whether it's apparent or not, I appreciate the time you've taken to offer explanation. I agree that adding the As far as CMake over-automating things, yes it is problematic. Especially when such behavior is undocumented. I have spent the last few months educating myself about CMake and how to use it correctly. I had been avoiding suffixes in the toolchain file because that was my impression of "correct" CMake. I have no problem changing that view. Also, thank you for the complex example project. I will make time to review it. |
|
You're welcome! I'm currently split between maintaining the Eclipse Embedded CDT (which I think is on the downslope now) and improving the VS Code xPack extension (which I'm optimistic about), so any suggestions are welcome. |
BTW, I think that this can be fixed. Try to discuss this in the CMake forum and explain as clear as possible that, on Windows, when CMake encounters a name without extension, if that file is not present or it is not an executable, CMake should check if a similar If they agree on such an enhancement, we can experiment in my CMake fork and eventually provide a pull request. |
and only if none is available, pick the name without extension. I think that's it right there. It can auto-append both the |
|
As far as the Eclipse Embedded CDT, I'm a big fan and plan to continue using it. I don't think the VS Code embedded experience has reached the maturity level of Eclipse, nor do I think VS Code's UI is as well thought out. My opinion is a minority opinion though ... by a wide margin. Even the MCU on Eclipse blog is on that bandwagon. My suggestion is to focus on VS Code. I may love Eclipse, but as far as the templates I'm working on, I'm focusing on VS Code. That's what my coworkers use. That's what clients ask about. One aspect of modern embedded is management of dev environments. That's something that this extension is helping to make very easy. It's literally "Check out repo. Click button." If you make Being able to have a simple |
Just curious, did you try the xPack project templates? There are two of them now, one with the @xpack/hello-world-template also used by the xPack extension, and an older one, the @sifive/templates. I plan to further enhance this style of templates, so if you have any suggestions, they are welcomed. |
|
The templates I'm working on are based heavily on the CMake courses from Embedded Artistry. I found out about the xPack build framework only after starting work on the templates. I was originally looking at Conda to manage dev environments as described by Tyler Hoffman. xPack is a better solution. I have looked through the hello-world template, but like I said, the design of my templates is already heavily influenced by Embedded Artistry. There is one comment I would make. I do not have a Take that for what it's worth. Everything else I've seen treats CMake builds as two separate stages that need to be run independently. As far as Maybe it can't be done in the toolchain file? |
|
I do like the scripting for template setup. There's a lot of work here. Like I said. I'm fairly new to Node.js and am still wrapping my head around |
Yeah, I know that you can do lots of tricks with CMake, but the xPack framework is neutral to the build system, you can use any tools, and the general case is with separate steps. Actually I plan to implement an integrated build system in xPack and VS Code, similar to the Eclipse managed build, with the configurations stored in JSON files and editable via nice GUI pages, as in Eclipse.
Indeed. I think that scripted templates, used with |
It shows how to organise multi-platform unit-tests for a source library project intended to be included in embedded projects. The library being highly portable (it manages intrusive lists), the tests can be compiled and executed both as native processes on the development platform, or as embedded applications. For now only Cortex-M4 tests are included, but once the new toolchains I'm working on right now will be available, I'll extend the tests with Cortex-A and RISC-V applications. I doubt you saw many embedded projects running such extensive multi-platform tests and in such a convenient way. |
The problem was reported as #27.
The output console displays:
In case a different toolchain is installed somewhere, it will be picked, and IntelliSense will be able to process the header, but it is not correct.
The text was updated successfully, but these errors were encountered: