Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
The easiest way to do that would be to use the Import Existing Project mode of the Linux Project Wizard. It will not automatically read the settings like CFLAGS, but will automatically add all source files from the specified directory. Then you can customize it further via VisualGDB Project Properties.
You can also try v5.2 Preview 1 that will automatically repair missing include paths once you open the source files that have some missing includes.
support
KeymasterHi,
This looks like a possible conflict between the 2 rule definitions (or explicit and implicit rule definitions). Could you post the entire Makefile here or search it for references to LCDConf.c and check if they match the actual file location?
July 25, 2016 at 15:14 in reply to: Getting warning about overriding recipe and ignoring old recipe on library proje #8698support
KeymasterHi,
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 #8695support
KeymasterHi,
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?
support
KeymasterHi,
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.
support
KeymasterHi,
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.
support
KeymasterHi,
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.
support
KeymasterHi,
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
support
KeymasterHi,
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 #8664support
KeymasterHi,
Thanks, we have fixed this. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.952.msi
support
KeymasterThanks, 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.
support
KeymasterHi,
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/
support
KeymasterYes, 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.
support
KeymasterHi,
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).
support
KeymasterHi,
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
-
AuthorPosts