[support]

Hi,

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]

Hi,

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?

[support]

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.

[support]

Hi,

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]

Hi,

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]

Hi,

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]

Hi,

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]

Hi,

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]

Hi,

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.

[support]

Hi,

Thanks, we have fixed this. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.952.msi

[support]

Thanks, 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]

Hi,

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]

Yes, 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]

Hi,

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]

Hi,

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

 

[Author]

Posts