Review the logic for setting the PATH with preferXpacksBin

[ilg-ul]

Review the logic for setting the PATH with preferXpacksBin

[ilg-ul]

@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?

[jonahgraham]

@ilg-ul I'll try to come back to it, but more critical items have creeped in my todo list.

[ilg-ul]

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. :-(

[ilg-ul]

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.

[ilg-ul]

I did an attempt to fix this issue in commit 2eea055.

Please review it and let me know if this is what you meant.

[jonahgraham]

String xpackBinPath = project.getFolder("xpacks").getFolder(".bin").getLocation().toOSString();

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

[ilg-ul]

Ok, thank you. Then I'll proceed with the release.