Thanks for renewing your support.

Our CrossWorks project importer uses the .ind files to determine the full list of implicit sources (coming from CrossWorks packages) used to build the project. In our experiments, this was the only way to locate these implicit dependencies that are otherwise not referenced anywhere.

You can actually find the logic used by the CrossWorks importer here. We intentionally publish the sources for all project importer plugins, so that our users can tweak them to their needs.

In this case, you can simply ignore the warning about the .ind files and proceed with importing the project anyway. If the resulting project won’t build due to missing symbols, you can try examining the map file produced by CrossWorks, or searching the object files in its build directory for the definitions of these symbols, and manually adding the corresponding files to the VisualGDB project.

In general, when it comes to importing projects from other tools, VisualGDB can automatically parse common settings (list of source files, include directories, preprocessor macros, device type, etc.), but indeed, it won’t translate every possible setting from the original project file. This speeds up the importing process compared to creating a new project and adding everything there manually, but indeed requires minor adjustments to accommodate the settings that could not be translated automatically.