VisualGDB 5.6 Clean And Source line Build Fail connection

[lashmuelE]

Hello,
I start using VisualGDB from version 5.4
When i switch to version 5.6 within Visual Studio 2017 then 2 functionalities stop working in this version:
1) The clean (and therefor rebuild) operation is Failed meaning no obj is deleted and i have to physically delete those files
2) when there is a build fail and press the line that shows the fail instead of jumping to the fail source line i get error as the attached file  VisualGDBCapture.jpg (and when i press the Yes button i see the Windows in VisualGDBCapture1.jpg and then VisualGDBCapture2.jpg accordingly).
3) also for every file includes in the build i get warning as follows “No remote path corresponds to ..\..\src\tws_du\cfg\p2t_cfg.cpp. Please configure VisualGDB to upload it to the target via VisualGDB Project Properties -> Synchronized Directories, or Custom Build Steps.” even if the build succeeded. trying to do what the VisualGDB suggest i get VisualGDBCapture3.jpg and i’m not sure what to do.

Waiting for your response

Best regards

Shmuel

Attachments:

You must be logged in to view attached files.

[support]

Hi,

No problem, we can help you get it working. The issues you are describing are likely caused by 2 changes from VisualGDB 5.4 to 5.6:

1. Instead of placing all object files into 1 directory, VisualGDB 5.6 tries to place them into respective subdirectories. This allows building projects that have multiple files with the same name (e.g. subdir1\source.cpp => build\<…>\subdir1\source.obj  vs. subdir2\source.cpp => build\<…>\subdir2\source.obj). If you build the old project with VisualGDB 5.4, all object files will be placed directly in build\<…>. If you then open it with VisualGDB 5.6, it will indeed expect the object files to be in subdirectories and won’t remove them from the old location.
   There are 2 workarounds to this issue:
   1. You can set the VS Project Properties -> General -> Preserve Subdirectories for Object Files to False to restore the old logic for placing object files. The project will work the same way as it did for VisualGDB 5.4, although having multiple sources with the same name won’t be possible.
   2. You can manually clean the object directories (remotely and locally) when switching from v5.4 to v5.6. This is only needed once – after you build the project with VisualGDB 5.6, it will be able to locate and clean the object files just fine.
2.  When dealing with the source files outside the project directory (not covered by any path mapping rules), VisualGDB 5.4 assumes that the relative path on the Linux side would be the same as on the Windows side (e.g. if a project located c:\projects\app is mapped to /home/test/app references ../shared/tool.cpp, VisualGDB would map it to /home/shared/tool.cpp). This caused weird errors for users that had different path layouts on Windows and Linux sides, and if some additional MSBuild rules translated the relative path to absolute, so we changed the path mapping logic as follows:
   1. First, VisualGDB would resolve the relative path to absolute one (e.g. c:\projects\shared\tool.cpp).
   2. Then, it would explicitly check the path mapping rules for a rule covering this path. The following locations are checked:
      • Main source transfer command defined in VisualGDB Project Properties -> Project Settings.
      • Additional path mappings from VisualGDB Project Properties -> Path Mappings.
      • Additional custom source directories (VisualGDB Project Properties -> Synchronized Directories).
      • Additional directory transfer actions in VisualGDB Project Properties -> Custom Build Steps).

   If you are switching from VisualGDB 5.4, please try locating the sources files in question on the Windows machine, and then make sure their directory is covered by one of the settings listed above (e.g. you can add a path mapping from c:\projects to /home/test to cover anything inside c:\projects and any of its subdirectories).

Also if you have a complex project structure involving multiple applications and libraries, please consider switching to Advanced CMake. It allows having just one VisualGDB-level project (with one copy of source transfer settings, debug settings, etc.) with multiple applications, libraries and other custom targets, dramatically reducing the duplication of settings between applications and libraries.

[lashmuelE]

Hello,

1. Trying to delete the remote object directories (under VisualGDB directory)  and local (C:\Users\users\AppData\Local\VisualGDB\…) did not solve the problem so i set the Preserve Subdirectories for Object Files to False and now clean is OK.
2. You suggest Add a path mapping to any of 4 locations (VisualGDB Project Properties -> Project Settings\Path Mappings\Synchronized Directories\Custom Build Steps)
   I’m not sure which path to add. i have many relatives path for every project in my solution. do i have to add all of them? other path? do you have example of how i can Add this path?

   Shmuel

[support]

No problem.

If the clean didn’t work, the project might have been using custom clean rules, expecting the object files to be in that location. Either way, disabling the Preserve Subdirectories for Object files setting would fully restore the old behavior.

The easiest way to get the paths working would be to add a mapping to VisualGDB Project Properties -> Path Mappings. We would advise proceeding like this:

1. Start with a specific source file that is not working. Take a note of its path on Windows (e.g. c:\projects\shared\test.cpp) and on Linux (e.g. /home/test/shared/test.cpp).
2. Add a mapping to the Path Mappings page covering just the file directory (e.g. c:\projects\shared => /home/test/shared).
3. If you have multiple project files, make sure you edited the correct one. To avoid confusion, we would advise temporarily unloading other projects from the solution.
4. Confirm that the mapping fully fixed the problem for this file.
5. Once the problem is fixed, try changing the mapping to be as generic as possible (e.g. c:\projects => /home/test) and adding it to other projects.

There might be an easier way to get it working (e.g. using the Synchronized Directories page). If you could give us a brief description of your directory structure (i.e. why are some files located outside the project regular folders, and how do you usually synchronize them between Windows and Linux), we can try to suggest a more universal way to handle it.

[lashmuelE]

Hello,
I created a project as you can see in the screenshot VisualGDBProjectSettings.JPG
I had to create environment variable $(ProjectDirLinux) that defined automatically the Linux project directory as exists in windows at the variable $(ProjectDir). no such variable for Linux.
It Works great for Build and Debug
So i tried to Define the path you suggested in VisualGDB Project Properties -> Synchronized Directories using that variable (ProjectDirLinux) as you can see in VisualGDBSyncDirectories.JPG
then i create a deliberate compile error but when i press error line in FailureLine.JPG i get the error message in VisualGDBFailureOpenException.JPG
What i did wrong?
Best regards
Shmuel

Attachments:

You must be logged in to view attached files.

[support]

Hi,

No problem, please see below for the list of suggestions:

• You have configured VisualGDB to synchronize the directory of every project using MRS-RDP-LINUX to the same remote directory defined via environment $(ProjectDirLinux). It means that whenever you open ANY project using the Linux machine, the contents of its directory will be copied to $(ProjectDirLinux). If you have the .vcxproj/.vgdbsettings files in many different directories, it will copy them ALL into the same $(ProjectDirLinux) directory. You probably didn’t intend to do that – if you just want to create a path translation rule, the setting on the Project Settings page is sufficient. Synchronized Directories page configures VisualGDB to physically copy files to certain locations. If you are copying the files manually, you do not need this setting.
• The error message on the screenshot mentions the ../src/bit/bit.cpp file. It is located outside the project directory, so whatever path mapping you set for $(ProjectDir) wont cover it, because the path is not inside $(ProjectDir).

Please consider setting up a path mapping on the Path Mappings page instead. Make sure the mapping you create covers the actual location of the bit.cpp file. If you are not sure, please let us know:

• The full path of the ../src/bit/bit.cpp file on Linux.
• The full path bit.cpp file on Windows.

We can then help you get the mappings working. Note that if N: is a Linux network share, you can simply map N:\ to the Linux path of that share using the Path Mappings page. It will automatically cover all paths inside N:.

[lashmuelE]

Hello,
The variable $(ProjectDirLinux) was created because i understood that Local directory (windows) and Remote directory (Linux) should point to the same directory where the project file is located.
Since i have $(ProjectDir) that defines automatically the project path to windows and i don’t have such variable for Linux, so i had to create $(ProjectDirLinux).
You wrote “the contents of its directory will be copied to $(ProjectDirLinux)” i guess you meant the compiler output (such as obj files)
you also wrote “it will copy them ALL into the same $(ProjectDirLinux) directory” but the projects in the solution are stored in different directories, hence $(ProjectDirLinux) creates different path for each project.
The full path of bit.cpp in windows is: n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsg_cmp\src\bit.cpp
The full path of project file that include bit.cpp is: n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsc_cmp\projects\rdp.vcxproj
N: is network drive in windows
6731_omfv is folder that mounted from the Linux build machine to N drive hence the full path in Linux to bit.cpp file is: /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsg_cmp/src/bit.cpp
Also when i go to Custom build steps and press the “Test the command now” (for ProjectDirLinux) i get: “Success: ProjectDirLinux=/6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsg_cmp/projects”

Best regards

Shmuel

• This reply was modified 1 year, 11 months ago by support. Reason: highlighted paths

[support]

Hi,

No problem, we will clarify.

The variable $(ProjectDirLinux) was created because i understood that Local directory (windows) and Remote directory (Linux) should point to the same directory where the project file is located.
Since i have $(ProjectDir) that defines automatically the project path to windows and i don’t have such variable for Linux, so i had to create $(ProjectDirLinux).

It generally depends on how you created $(ProjectDirLinux). You mentioned environment variable, so we assumed it’s something defined in Windows environment (configured via Control Panel->System Settings), that would be the same for all projects. If you defined it as a custom per-project variable, it should be fine.

You wrote “the contents of its directory will be copied to $(ProjectDirLinux)” i guess you meant the compiler output (such as obj files)

We meant that according to the last screenshot from your previous post, VisualGDB will copy the *.cpp; *.h; *.hpp; <…> files from $(ProjectDir) to $(ProjectDirLinux) for every project that targets MRS-RDP-LINUX. Depending on how ProjectDirLinux is defined, this may work as expected, or may not work at all.

Either way, you mentioned the following paths of the file:

• Windows path: n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsg_cmp\src\bit.cpp
• Linux path: /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsg_cmp/src/bit.cpp

You should be able to get everything working by going to the Path Mappings page of VisualGDB Project Properties for rdp.vcxproj and adding the following mapping:

• Windows path: n:\6731_omfv
• Linux path: /6731_omfv

It should cover all the files inside /6731_omfv. You do not need the entry on the Synchronized Directories page, or any other entry. This entry alone should be sufficient to cover all paths.

[lashmuelE]

Hello,
i tried your solution and still doesn’t work
When i press the open directory button and select the 6731_OMV directory (as seen in PathToMountDirectory.JPG) i get automatic complete of $(ProjectDirLinux) to 6731_OMFV as seen in PathMappingAfterSelectLinuxDirectory.JPG
When i manually type the Linux path and start with / i get “nothing found” comment and of course this option also doesn’t work.
Also attached 2 more files to clarify the ProjectDirLinux
Best regards
Shmuel

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Thanks for clarifying this. The “$(ProjectDirLinux)6731_OMFV”  path suggestion is definitely wrong. It is likely suggested because VisualGDB checks the variable list before ProjectDirLinux gets assigned (and hence defaults to an empty value). We have added an extra check on our side to avoid suggesting empty variables in paths, although manually replacing the path with /6731_OMV should work.

Either way, we have double-checked the screenshots you provided and found a few inconsistencies:

1. The project path on the Windows machine is n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsc_cmp\projects\rdp.vcxproj. The corresponding project directory on Linux should be /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsc_cmp/projects.
2. The Linux path of bit.cpp you mentioned is /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsg_cmp/src/bit.cpp.
3. The relative path reported by gcc is ../src/bit/bit.cpp. Given the base directory, it should translate to /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsc_cmp/src/bit/bit.cpp, that doesn’t match the path in the previous step.
   
4. The Windows path computed by VisualGDB when you tried navigating to the file was n:\6731_omfv\SHMUEL\tdp_develop-linux_test\tdp\dsg_cmp\src\bit.cpp. The _test part should not be coming from the project settings shown on the screenshot.
   

Our best guess is that you have multiple projects that use slightly different (although confusingly similar) file names, so you are changing the setting for one project, while building a different project. Hence, the settings in the VisualGDB Project Properties do not appear to take effect.

The easiest way to unwind this would be to remove all projects but one from Solution Explorer, get it working for just one project, and then add the rest of the projects back, one half at a time, and verifying that paths still work. Another option would be to to follow the inconsistencies we pointed out (e.g.the extra /bit part and the _test part). They must be coming from some setting in a different project, and searching the project/settings files for these parts might explain what is going on.

[lashmuelE]

Hello,
i made mistake on the bit.cpp path. the correct path is /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsg_cmp/src/bit/bit.cpp and not as i mentioned before. so there is a match.
also the window path computed by VisualGDB is n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsc_cmp\src\bit\bit.cpp  and not what you mentioned in par 4.

so in short there is no inconsistencies as far as i understand.

does it change the your conclusion? do you have other suggestion now?

[support]

We only mentioned the path in step #4 because it was shown on the screenshot. If it’s not relevant anymore, could you please double-check what happens when you try clicking on the message in the VisualGDB Build window? Do you see another error message with the n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsc_cmp\src\bit\bit.cpp path?

If yes, please try using the File->Open command in Visual Studio, and pasting n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsg_cmp\src\bit.cpp there. If the file cannot be opened, please double-check the path and permissions. If the Windows path of the bit.cpp file is different, the path mapping will need to be updated accordingly.

If you get a different  error message, please make sure you expand the details view to see the path, and attach an updated screenshot here.

[lashmuelE]

Hello,
Sorry for leaving this post for long time. I wanna solve this issue this time.
Shortly, i created error compilation in file N:\6731_OMFV\SHMUEL\rdpMRS\rdp\dsg_cmp\src\main.cpp. the full path in Linux is  /6731_OMFV/SHMUEL/rdpMRS/rdp/dsg_cmp/src/main.cpp

when i tried in Path mapping to define /6731/omfv and in windows section N:/6731_omfv.
when i press the error link i get VisualGDB error dialog: Failed to open ‘/6731_OMFV/SHMUEL/rdpMRS/rdp/dsg_cmp/src\..src\main.cpp(322)’.
Please advise what i must do to get/jump to error line on mouse click

[support]

Hi,

Based on what we see, it looks like you have several files with very similar paths, and some mapping rules that look almost correct, but are off in some very subtle way.

In order to fix it, you would need to double-check all the paths and mappings.

First of all, please remove all secondary projects from Solution Explorer, so you only have 1 project )it will only affect the .sln file). This will ensure you are changing the settings for the same project that is generating the error messages (otherwise the settings will not change anything). Then, please share the screenshots of the following:

• The exact error message shown when you try to open the file.
• The exact message in the build log (VisualGDB Output -> Build -> Log, not the error list).
• The Project Settings, Synchronized Directories and Path Mappings pages of VisualGDB Project Properties.
• Solution Explorer showing only one project in the solution.

Once you get it working with just one project, you can try restoring the .sln file from the backup, or re-adding the projects manually. If the problem starts happening after adding a specific project, please let us know and we will advise you on the troubleshooting steps.

[lashmuelE]

Hello,
i created test solution for easier problem demonstration

Attachments:

You must be logged in to view attached files.

[Author]

Posts