Forum Replies Created
-
AuthorPosts
-
July 25, 2016 at 15:14 in reply to: Getting warning about overriding recipe and ignoring old recipe on library proje #8698supportKeymaster
Hi,
It’s still hard to say what exactly would be causing it. Normally the 2 line numbers reported by Make would point to the old and new definition, but in your example one of them points at an empty line (or a different Makefile). You can try commenting out the mentioned rule definition and running “make -d Release/Drivers.a” explicitly. If the build succeeds, examine the debug output generated by the -d option to see where else did it find the rule to build the file.
July 24, 2016 at 19:17 in reply to: Getting warning about overriding recipe and ignoring old recipe on library proje #8695supportKeymasterHi,
The Makefile looks normal, so it’s hard to say what is causing this. Perhaps it has some strange inclusion loop and ends up included twice?
Can you try re-creating the project with the VisualGDB wizard and check if the warning re-appears?
supportKeymasterHi,
We are talking about this post. By deselecting the –begin-group and –end-group options you have made the linker sensitive to the order of the inputs. If you enable those options back, it should solve the problem.
supportKeymasterHi,
Normally VisualGDB uses the –begin-group/–end-group options exactly to avoid the need to specify the library order manually.
If you want to specify it manually and not use –begin-group/–end-group, you can do that by removing “winmm” from the “Library Names” field and manually putting the mix of “-lwinmm” and your .lib file in the correct order in the “Additional linker inputs” field.
supportKeymasterHi,
We are sorry that things don’t always work the way they are intended. We do have an extensive set of tests covering all major scenarios, but they do skip some rare cases like this one.
We do fix the reported issues very quickly though. This is already fixed in the daily build and will get into the next Preview of v5.2.
supportKeymasterHi,
We have just rechecked that and confirm that the namespace content indentation follows the generic “indent braces” setting. We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.954.msi
supportKeymasterHi,
Yes, if the $(file) command works properly for your make.exe, it is the preferred way.
Another alternative would be to use CMake (VisualGDB supports it for MinGW projects). We are also planning to add MSBuild support to VisualGDB 5.2 that will use the response files automatically.July 20, 2016 at 05:16 in reply to: Error on SSH connection with public key since release 5.2 preview 1 #8664supportKeymasterHi,
Thanks, we have fixed this. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.952.msi
supportKeymasterThanks, there was indeed a bug with this setting for MinGW projects. We have fixed this in our development branch and will include a fix in the upcoming Preview 2.
supportKeymasterHi,
Could you check the contents/size of the Debug/WindowsProject1.exe.in file? Does it list the files correctly or is it cut off?
Regarding the Linux Kernel, we actually have a separate project for that – VisualKernel. You can look through this tutorial to get a brief idea: http://sysprogs.com/VisualKernel/tutorials/kernel/
supportKeymasterYes, this is a known Visual Studio problem. What VisualGDB actually does for large folders is unloads the entire VS project, edits it manually and reloads it back.
Manually adding a lot of files via Visual Studio command would cause a HUGE delay. Note that this delay does not come from VisualGDB and happens with any other Visual Studio project.
supportKeymasterHi,
Sorry, this more looks like a VS limitation than VisualGDB one. Please try disabling the Clang IntelliSense engine via Tools->Options->VisualGDB. If this does not affect the slowdown, this is not caused by the engine. Then please try disabling all other VS extensions (e.g. Resharper or VisualAssist).
supportKeymasterHi,
Our support is located in the PST timezone, so we could not have answered you earlier. Sorry about that.
You can configure VisualGDB to pass a list of source files via response files by modifying your Makefile as follows:
ifeq ($(TARGETTYPE),APP) $(BINARYDIR)/$(TARGETNAME): $(all_objs) $(EXTERNAL_LIBS) $(LD) -o $@ $(LDFLAGS) $(START_GROUP) $(all_objs) $(LIBRARY_LDFLAGS) $(END_GROUP) endif
should be replaced with this:
ifeq ($(TARGETTYPE),APP) $(BINARYDIR)/$(TARGETNAME): $(all_objs) $(EXTERNAL_LIBS) @echo $(all_objs) > $@.in $(LD) -o $@ $(LDFLAGS) $(START_GROUP) @$@.in $(LIBRARY_LDFLAGS) $(END_GROUP) endif
supportKeymasterHi,
We have actually tested it on huge projects like the Linux Kernel (~9000 files) and we have heard from other customers using it with large codebases. So this looks like something might not be working properly in your case.
Normally VisualGDB does all the indexing in the background, so you only need to wait if you start something like “Go To Definition” (VisualGDB will display the progress and the information on whether it’s using all cores). If you are waiting for something else, perhaps it’s caused by some other Visual Studio extension or VS itself? Could you clarify what GUI do you see when you wait?
July 19, 2016 at 19:08 in reply to: Clang-based Intillisense engine "Insert spaces" doesn't work #8651supportKeymasterHi,
It looks like VisualGDB is not getting initialized properly. Does this happen when you open the project from command line, or also when you close the solution and open it again?
-
AuthorPosts