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
Review the logic for setting the PATH with preferXpacksBin #580
Comments
@jonahgraham, v6.4.0 is almost ready, this is the only pending issue. Do you think we can solve it before 2023-09 closing date? |
@ilg-ul I'll try to come back to it, but more critical items have creeped in my todo list. |
What is the 2023-09 closing date? If things get that busy we can delay it for -12, but I'd prefer to have it in -09, to remove this item from my todo list, since I don't plan for a new release in the near future. I might also try to address it myself if you explain me what the problem was, since I did not understand it from your previous PR. :-( |
I took a closer look at your explanations in #576, and, if I got it right, you identified a bug in the following sequence: IPath projectPath = project.getWorkspace().getRoot().getLocation().append(project.getFullPath());
IPath xpackBinPath = projectPath.append("xpacks").append(".bin");
path.add(xpackBinPath.toOSString()); and suggested: String xpackBinPath = project.getFolder("xpacks").getFolder(".bin").getLocation().toOSString();
path.add(xpackBinPath); This should produce a correct path, even if the project is not stored in the workspace. I tested this with a project created via the QEMU Arm xPack template outside the workspace and the build passed, so I guess this is ok. |
I did an attempt to fix this issue in commit 2eea055. Please review it and let me know if this is what you meant. |
That is what I meant. What held me up here is that I didn't take time to understand the other parts of your request, but seeing what you changed it LGTM |
Ok, thank you. Then I'll proceed with the release. |
This issue was discussed in #576.
For projects that use xpm/npm dependencies, the tools are local to the project, and the
PATH
should be set to guarantee that these local tools are used.To test such configurations, the xPack Arm template can be used to generate projects with dual identity, as Eclipse projects and as standalone command line projects.
For more details, see Hello World Arm & RISC-V QEMU xPack templates.
The text was updated successfully, but these errors were encountered: