Forum Replies Created
-
Posts
-
1. Have multiple source file sync options. For instance, even if nothing changes, it still takes a long time for VisualGDB to get past the sync stage since it is checking all the files. What would help is to have multiple sync groups. I can have an “All” sync group, in which case all files are synced after I got new sources for my whole tree. Then I can also have a “Debug” sync group that only contains files/folders that I know I will be working on. This way, when VisualGDB tries to sync the files, it will be much faster since it only checks the sub-group of files in my “Debug” list.
That could be considered as a future feature. The usual solution to long file syncing times is to use shared folders to avoid syncing all together. That is why in the Linux wizard there are several options on where to store source files, VisualGDB can set up both Windows and Linux shares for you. In Tools->Shared Folder Manager you can also make and manage shared folders with VisualGDB at any time.
2. Can I start debugging without going through a build stage? Right now if I press F5, it syncs the files (see above), then initiates the remote build. However that build is really slow, even if everything is up to date (~10 minutes). So this is a real productivity killer if all I want to do is start debugging but I know the project is already up to date. I guess I can select to attach to an already running project. I’ll need to play with all the options to see what will work.
Trying to build before running happens due to a general Visual Studio setting. In Visual Studio go to Tools->Options->Projects and Solutions->Build and Run to change what to do on run. On normal Visual Studio projects Visual Studio is able to track whether a project is up to date very easily making this option very fast, but with make-based projects Visual Studio needs to poll make whether building is required and on large projects this can take a while.
The main binary and the main deployable executable need to be set to one file, not several files. This executable is given to gdb for debugging and gdb expects one file. The rest of the files this binary depends on should be moved to the deployment machine separately.
Consider converting the project from Linux to Custom, custom projects allow executing arbitrary sequences of commands for building and debugging. We have a tutorial at http://visualgdb.com/tutorials/linux/convert/ where we convert a project to custom to move a generated output file from the deployment machine to the windows development file, in your case you need to add the copying of the deployment binaries to the ‘actions before launching GDB’.
The conversion from Linux to Custom is made to convert the build and debug commands so that in the converted project building and debugging will work as before. If you have made several changes to your Linux project, it may be a good idea to make a backup copy of the vgdbsettings file before converting.Yes, currently password protected private keys are not supported as we thought that there was no demand for such a feature. If it is a vital point to you, we could add support for it and release a quick patch.
What you are describing is a Visual Studio issue listed here: http://connect.microsoft.com/VisualStudio/feedback/details/519904
Please try following the official Microsoft fix described here to repair your Visual Studio installation: http://support.microsoft.com/kb/2519277Do not copy the source files to a new location from the Makefile location, the source tree shown in Visual Studio projects is only for the convenience of sorting and opening the files and does not refer to the physical location. Adding new files to the project only adds the files automatically to the Makefile if you are using the VisualGDB generated Makefile. You do not need to import the project again if you add files to CMakeLists.txt, importing is just meant for the convenience of importing the entire source at the beginning of a project. Putting it all together, import the source and Makefile, CMakeLists.txt when making the project, make sure the project builds, when adding files later on, make sure you also add them in the Makefile.
Better handling of CMake projects is currently being considered as a feature for the next VisualGDB version. If you have any feature suggestions, let us know.
Thank you for your suggestions. We have made a note of it for the next version’s feature list. Please also consider switching from using the VisualGDBBuildServer to using SSH, which became supported since VisualGDB 3.0.
This seems to be a bottleneck of GDB with large projects. To disable the issuing of this command go to VisualGDB Project Properties->GDB Settings and check the “Use relative source file paths” option.
All assets for native apps, ‘pure’ or not, should be stored in the “assets” folder in the project directory on the same level as the “jni” folder. Then the Android build system knows to include them in the app apk file.
The folders in the VisualGDB project do not necessarily reflect the folders on the harddisk and are just used to visually group the existing files.
Thus you can add the asset files in the Resources folder to easily edit them from Visual Studio, but they need to physically be in the “assets” folder in the project directory.Thanks for the bug report. We have located and fixed the problem. The fix will be included in the upcoming 2.8 release.
The problem was only with the older gdb versions, gdb 7.1 and later versions work normally.
It is taking a long time because all the logs stored on the Android device are re-fetched each time debugging begins. In order to not interfere with other logcat showing tools, the logcat window is made not to delete the logs from the device when they are fetched. Thus if the Android device has been running a long time, the logs have been accumulating as well.
Currently there are two ways to solve the slowness:
1) Display the logcat all the time for the debug Android device. Then the messages are updated constantly and the messages won’t be re-fetched when debugging begins. To display the logcat between debugging sessions go to ‘Android->View LogCat’.
2) Clear the logcat on the Android device manually. For this go to ‘Android->Open Android shell’ and enter the command ‘logcat -c’ there. Please not that this will irreversibly delete all the stored logcat messages from the device.
