views:

1556

answers:

7

Is there a way to utilise the GCC compiler whilst still being able to develop via the Visual Studio IDE?

Our project is cross-platform, and I quite frequently get into trouble from my colleague because I'm checking in code that's not standards compliant (this can be attributed to the VS compiler!).

I'd still like to be able to compile using the MS compiler, so I can continue debugging, etc, however I'd like to be able to switch to compile using GCC, just so that I can be sure I'm not breaking the build on other platforms.

Is this possible?

A: 

I had to maintain separate makefiles for compiling with gcc. There's an upfront cost associated with learning make, but you'll benefit from the intimate knowledge of your code and the differences between VS C++ and gcc. When I did this, I was using VC 6, so there may be a better way now with VS 2005.

dwilkins
A: 

Try Cygwin, as long as you set up all your Makefiles correctly you can always try to compile both on VS and on GCC

+1  A: 

I don't think there is a simple switch, because gcc's command-line options are very different from VSs. In any case, just running the compiler will be non-trivial, as your build system probably sets a bunch of preprocessor defines and build variables that need to be set for the compile to succeed.

If your colleague is working on Unix, he probably has a make, scons or cmake-based build system anyway. You can use Cygwin to install the standard Unix toolchain on Windows, including gcc, make, flex, bison and all the other Unix goodies. There are native versions of scons and cmake, but those will try to use VS, so that won't help you. I haven't tried installing them through Cygwin to see if that forces them to gcc, but that might not be relevant to you.

Creating a make system that uses the VS compiler is possible but painful (been there, done that). And a different question. ;)

You can then use a special buildstep to run the gcc compile from inside VS. It would be better to have a separate build target (like Debug and Release), and you can create those in the project files (they're just ASCII files, check them out), but I'm not enough of a VS person to know how easy that would be to do. Keeping it up-to-date will be a little painful, you might want to write a script to create it automatically.

DirkReiners
A: 

it depends how complex your project files are:

you definitly need a gcc environment like cygwin.

  • for small projects or single file compile you can use a custom build tool (rules-file)

  • for large projects/solutions I'm auto-generating an autotools configure/makefile from the vcproj/sln-file and compile this inside the IDE. source files/lines of warnings and errors of gcc get translated to their IDE-equivalent (clickable in output window).

+1  A: 

There are certainly ways to do this -- this is how we develop for the PS3 with sony's toolchain (which is based on gcc). I don't know exactly how that works, but it integrates pretty seamlessly into VS.

I think what you need to do is either set it up to build with a makefile (probably easiest) or to write a wrapper program that converts VC arguments to gcc ones. Also, if you want the error/warning output in the VS format (so you can click it and get that file/line up in the editor), you need something to convert the output.

This stuff may help you in a related discussion about using VS with WRS/VxWorks version of the gcc tools:

Especially note the program linked there which converts the error output.

slicedlime
A: 

Presumably you're already using makefile to build your project, since it's cross-platform. Just make your VS project a makefile project with different project configurations that kick off the makefile using different parameters to indicate whether or not a build is for MSVC or GCC.

If your MSVC makefile build is capable of building debug files (PDB) - which it should be able to do, then the VS Debugger will work seamlessly as well.

Then building using GCC inside Visual Studio is as simple as selecting the 'GCC' configuration dropdown on the toolbar.

Michael Burr
+2  A: 

What I am about to suggest would still require a makefile, so I am partially repeating the advice above. Or, as was also mentioned earlier, maybe you already have a makefile, in which case you will have even fewer steps in order to accomplish what I am about to describe.

Once you know what your machine-specific windows command-line command would be for invoking make or g++ on your code, then you could create a "Pre-Build Event" in your Visual Studio Project. ("Project Properties >> Configuration Properties >> Build Events >> Pre-Build Event").

The pre-build event can call a bat file script, or any other script on your machine, and that script will be able to return an error-code. Essentially, "script OK," or "script FAILED" is the extent of the amount of communication you script can have BACK to visual studio.

I do not believe that the script automatically sees all the visual studio environment variables (such as $(InputDir), $(ProjectDir), $(SolutionName), etc), however you can use those variables when you specify how to call the script. In other words, you can pass those values to the script as arguments.

You could set this up so that every time you build your Visual Studio, the pre-build event will FIRST try to run make/g++ on your code. If your script (the one that calls make/g++) detects any problems, then the script returns an error and the build can be STOPPED right then and there. The script can print to stdout or stderr and that output should be visible to you in the Visual Studio Build output window (the window that usually shows stuff like "========== Build: 3 succeeded, 0 failed").

You can have the script print "BUILD FAILED, non-portable code detected, make/g++ returned the following:........."

This way, you don't have to remember to periodically switch from Visual Studio to the command line. It will be automatically done for you every time you build.

que que