VS code extension can't find some project files when included with Alire

[dalybrown]

Projects that seem to have their own actions for building / installing in non-standard places seem to be problematic for Alire and it results in all code being non-navigable.

For example, trying to include the Ada Web Server in a project (i.e., alr with aws) exposes this problem because AWS has actions to build/install itself when deployed. It seems like within the Alire environment the GPR_PROJECT_PATH is set correctly to the installed path of AWS, but VS code still complains. All code is then non-navigable. It is built properly though (as in alr build picks up the right environment).

It's easy to reproduce: just create a new project, with aws, and try to navigate the code. The issue seems to be present using shared and non-shared dependencies in Alire.

[dalybrown]

What's weird is even if I install the ada web server outside of alire into a standard place in my GPR_PROJECT_PATH using gprinstall ... VS Code still becomes problematic and I lose all navigation to all code. It seems to be something particular with that project because I've installed other projects to the shared location and VS code worked fine.

I noticed that occasionally it will actually find the projects if I just reload the window a few times in a row. There is a bug somewhere here.

[AnthonyLeonardoGracio]

Hello @dalybrown,

We'll try to reproduce on our side. Thanks for the report. We might come back to ask you more questions.

Regards,

[dalybrown]

Thanks. Yeah I don't know how else to precisely explain the problem. I can reproduce it in my environment easy enough though. I wonder if there is a race condition between indexing / finding all the projects and their sources and the VS code extension declaring there is a problem with the environment and giving up.

[AnthonyLeonardoGracio]

Are you using the VS Code remote mode?

[dalybrown]

Yeah... we develop in a docker container, so we are always using the remote development extensions. (Specifically, we use dev containers and so we use the builtin support of the remove development extensions for those.)

[AnthonyLeonardoGracio]

Ok I see, thanks for the quick answer.

As you may know, VS Code's environment management with the Remote mode requires to specify the environment per workspace, as described in our documentation here.

Have you already followed these instructions?

[dalybrown]

I did not see those instructions.

To be clear: this setup works without that most of the time. It is only the odd time (e.g., with the scenario I described above) where we see these issues. I set the GPR_PROJECT_PATH to the paths to projects that I use that are not managed by Alire (which, in this case, is AWS because the extension wasn't working when installing AWS with Alire).

I don't quite understand what the MAIN_NUMBER is though.

[AnthonyLeonardoGracio]

MAIN_NUMBER is just an environment variable's example, in that case to control a project's scenario value.

We'll have a look to the scenario you described. Keeping you posted.

Regards,

[reznikmm]

Could you try 24.0.6 version this too?

[dalybrown]

I will try this next week when I (hopefully) get back to coding. Thanks!

[XLCOLDJ]

Could you try 24.0.6 version this too?

On my aarch64 Mac I was having similar issues until this new release (the .workspace paths not updating, so no navigatin worked). It seems OK now, but it doesn't actually update the .workspace file until the project is closed and re-loaded (project-reload command doesn't work).

[dalybrown]

I get this error when using 24.0.6:

project file "/workspaces/XXX/alire/alr_env.gpr" not found

This is with a fresh crate. Something doesn't seem right still.

[Joebeazelman]

I've encountered the same issue and resolved it. It seems ALS is unable to access to the GPR_PROJECT_PATH environment variable which contains the path the projects dependencies managed by Alire. This is quite odd since Alire and ALS worked well previously. I suspect the current version of VSCode maybe the source of the issue.

Adding the following lines to your config or workspace file works, but interestingly, it continues to work even after removing them. I am now unable to reproduce the old error. Weird!:

	// Set a workspace-specific environment for Linux/OSX platforms
	"terminal.integrated.env.osx": {
		//  Set MAIN_NUMBER scenario variable to MAIN_2 directly from the environment
		"MAIN_NUMBER": "MAIN_2",

		//  Optionally, you can append the Ada toolchain of your choice to the PATH environment variable
		//  if you want to use a different toolchain.
		//  "PATH": "<PATH_TO_TOOLCHAIN>:${env:PATH}",

		//  Append the path to the directory containing print_utils.gpr project file dependency to
		//  the GPR_PROJECT_PATH environment variable
		"GPR_PROJECT_PATH": "./imported:${env:GPR_PROJECT_PATH}"
	},

[AnthonyLeonardoGracio]

I've encountered the same issue and resolved it. It seems ALS is unable to access to the GPR_PROJECT_PATH environment variable which contains the path the projects dependencies managed by Alire. This is quite odd since Alire and ALS worked well previously. I suspect the current version of VSCode maybe the source of the issue.

Adding the following lines to your config or workspace file works, but interestingly, it continues to work even after removing them. I am now unable to reproduce the old error. Weird!:

	// Set a workspace-specific environment for Linux/OSX platforms
	"terminal.integrated.env.osx": {
		//  Set MAIN_NUMBER scenario variable to MAIN_2 directly from the environment
		"MAIN_NUMBER": "MAIN_2",

		//  Optionally, you can append the Ada toolchain of your choice to the PATH environment variable
		//  if you want to use a different toolchain.
		//  "PATH": "<PATH_TO_TOOLCHAIN>:${env:PATH}",

		//  Append the path to the directory containing print_utils.gpr project file dependency to
		//  the GPR_PROJECT_PATH environment variable
		"GPR_PROJECT_PATH": "./imported:${env:GPR_PROJECT_PATH}"
	},

Hello @Joebeazelman,

This should not be needed since the ALS calls alr printenv to get the needed environment variables in order to load the project. We will have a deeper look on that issue, I guess we still have a bug somewhere.

Regards,

[Joebeazelman]

Ok I see, thanks for the quick answer.

As you may know, VS Code's environment management with the Remote mode requires to specify the environment per workspace, as described in our documentation here.

Have you already followed these instructions?

The documentation is wrong. Linux and MacOS are two separate platforms. You need "terminal.integrated.env.osx" in order for VSCode not to complain. Do you guys have access to Mac for development and testing purposes?

[AnthonyLeonardoGracio]

Ok I see, thanks for the quick answer.
As you may know, VS Code's environment management with the Remote mode requires to specify the environment per workspace, as described in our documentation here.
Have you already followed these instructions?

The documentation is wrong. Linux and MacOS are two separate platforms. You need "terminal.integrated.env.osx" in order for VSCode not to complain. Do you guys have access to Mac for development and testing purposes?

We can make the doc a bit more precise, but the idea is really to mention that users need to set terminal.integrated.env.* variables to setup their environment when using VS Code remote.

We don't have internal testing on Mac OS, but we have it on GitHub though. But this is documentation, not actual code, and thus it can' t be properly tested.

[AnthonyLeonardoGracio]

The doc has been updated for info.

[Joebeazelman]

Here's another symptom of the bug. If your project specifies a runtime in the project file, for instance Light-Tasking-Runtime-Stm32F04, it's aware of it just like any library. During compilation, however, ALS reports an error, claiming it "can't find a runtime for the language Ada." The compiler doesn't encounter this issue.

I suspect one part of ALS can find it, but another part of it can't. It may be related to path name handling.

[AnthonyLeonardoGracio]

@Joebeazelman Is it an Alire project? If yes, make sure to add alr in the PATH via the terminal.integrated.env.* settings. Otherwise, make sure to add the right cross-toolchain (for arm-eabi-gnat if your are using Stm32F04) in the PATH instead.

Let me know if the issue still persist after that.

Regards,

[Joebeazelman]

Thanks. Unfortunately, I can't reproduce the issue, it just happens once in a while. I think this issue and similar ones occur when there are multiple projects in the same workspace. Alire doesn't like it when its context changes, i.e. switching between manifests during the same execution instance. Since ALS needs to obtain information from Alire to function, it's conceivable the context is lost when ALS parses a file in a different project, but in the same workspace.

I asked about this issue somewhere else and Mosteo said there's a alr build -C _project_path_ option. I'm not sure if it runs another instance, or tells Alire to reload the context. Never tried it, nor have I seen it documented. You might want to Mosteo about it.

Anyway, I'm no longer having this issue, but will try to take notes when it does occur.