Forum Replies Created
-
Posts
-
Unless it contains assembly files that are incompatible with GCC, you can simply import it to VisualGDB. E.g. refer to the legacy project tutorial to see how to specify device-specific flags manually: http://visualgdb.com/tutorials/arm/legacy/
Normally C++ files should be handled as c++14 unless you have explicitly specified a different standard in your Makefile settings. Could you please double-check your CFLAGS/CXXFLAGS? You can see the effective IntelliSense flags via View->Clang IntelliSense Status->Project Status. Does the CXXFLAGS field specify -std=c++1y?
The handling of .h files depends on your project type. When you open a .h file, VisualGDB first checks if any of the source files includes it. If yes, it opens the .h file in the context of that source file. If no sources include the header file, it simply counts the C and C++ sources in the project. If there are 50% or more C++ sources, new .h files are treated as C++ includes. Can you please check how many C and C++ sources are in your project?
The command for switching between source and header files will be fixed in the final 5.0 release.
Yes, simply go to the IntelliSense Settings page of VisualGDB Project Properties and add “-include <forced include file>” to IntelliSense CFLAGS/CXXFLAGS.
You can change the syntax highlighting colors via Tools->Options->Environment->Fonts and colors->Text Editor. VisualGDB automatically uses the standard C/C++ colors from the normal Visual C++ package (if they are supported in your VS version) and adds a few elements of its own (e.g. “C++ Constructors and Destructors”).
Hi,
The easiest way to restore the broken Remote Console window would be to restore the .vgdbsettings file from your source control system. All debug settings are contained in that file and will be reverted by restoring it.
If that is not possible, please try creating a new project with the project wizard and see if remote console is broken there as well. If not, compare the settings in your project with the settings in the new project to see what can be causing the problem.
Hi,
VisualGDB currently does not support solution-wide variables. However, you can use 2 mechanisms to define things globally:
- Use SSH host aliases (see the SSH Host Manager window) to avoid hardcoding machine names in your projects.
- Reference environment variables using the same syntax as the per-project variables: $(VarName).
If this is insufficient, please let us know your scenario so that we could suggest a better solution.
Hi,
Can you attach a screenshot of the emmintrin.h file showing the error location and the color of tokens around it?
Does your project specify -std=xxx explicitly in compiler flags? Can you open View->Clang IntelliSense Status, switch to Project Status and share the value of CFLAGS and CXXFLAGS displayed there?
Please also confirm whether the problem happens while trying to edit a .c or .cpp file.
Hi,
I presume, you mean VisualGDB, not WinGDB. Yes, simply click “resynchronize toolchain” on the Build Settings page of VisualGDB Project Properties and VisualGDB will automatically fetch those files for you.
Hi,
You can specify NDK_MODULE_PATH via Make arguments in VisualGDB Project Properties (Build Settings page).
Hi,
You can specify NDK_MODULE_PATH via Make arguments in VisualGDB Project Properties (Build Settings page).
It might be possible in theory, but in practice many Cygwin-specific functionality will simply crash randomly because it will expect certain process-wide preparations to be made by the host executable (that will not be made as your EXE is not cygwin-based). You could try investigating and fixing those crashes, but using MinGW would be a much easier solution.
You do not need to copy the source code to the target machine. Although GDB running there won’t be able to locate the source files, it will report the file paths to VisualGDB. And as long as VisualGDB has the correct path mappings (configured via VisualGDB Project Properties), it will be able to map those paths to the correct source files on the Windows machine.
Hi,
Thanks for reporting this. Looks like VisualGDB missed one step in detecting the new library locations introduced in Android 5.0. Please try VisualGDB 5.0 Preview 4 and let us know if it works.
