My last post described how I have started using GCC 4.4 to compile my codebase so that I gain a little more portability, but more importantly I get some extra static code analysis without spanking my wallet. My Heath Robinson-esque solution involves using the free Code::Blocks IDE as it can import Visual C++ projects and solutions with minimal fuss, they are easy to maintain, and it's only an extra .cbp and .workspace checked into the SCM repository - so it's not messy.
As I mentioned before this was a suggestion from fellow ACCU member Steve Love, but since then I have had a some discussions on the accu-general mailing list to see what alternatives there are...
I guess the most obvious alternative would be Eclipse + CDT (C/C++ Development Tooling) as this mirrors my current setup of an IDE + GCC. Given the volume of development in Eclipse it also probably makes the most sense, but I have not had a good experience with Eclipse or CDT in the past - probably because I've been spoilt by the simplicity of installing and using Visual C++. I recently tried the CDT 5.0.x release but once again got lost in the Eclipse menus trying to configure it for my MinGW installation. This was in stark contrast to Code::Blocks where I had it configured in minutes. I guess I shouldn't be surprised that the learning curve of a tool as powerful as Eclipse is going to be much steeper, but it's just too steep for my VC++ biased plan at the moment. I should also point out that I haven't even opened the manual, so cries of RTFM are entirely valid and I only have myself to blame.
Both the Code::Blocks and Eclipse solutions rely on a separate IDE to manage the build process which is annoying because of the additional maintenance required to keep them in sync with the master Visual C++ projects. So, is there a way to drive GCC directly from the Visual Studio IDE?
A little bit of Googling during my earlier research led to a tool called gnu2msdev that translates the output of GCC to the same format that CL produces so that the Visual Studio IDE can navigate to lines with compilation errors. From this I discovered a number of posts suggesting the use of a makefile project, but they were more about using Visual Studio as an expensive text editor rather than compiling the same source with two compilers. It feels like there might be something possible along these lines and I'm going to continue investigating in the background.
I've never used the Intel C/C++ compiler, but another fellow ACCU member, Anna-Jayne Metcalfe of Riverblade, who knows a thing or two about integrating with Visual Studio, pointed out that Intel have managed the tight integration, so perhaps it would possible to do the same with GCC? I've looked at the MSDN documentation and it looks somewhat complicated for now :-) However, the signs are that it will be somewhat easier in the future as Microsoft have been slowly separating the IDE and build system so that it can support other languages and toolchains. The VS Project Team Blog has a number of posts on the changes to Visual Studio extensibility in VS2010 that show what they are up to.
For the moment I'm sticking with the Code::Blocks approach, not least because the .cbp file format is simple and I reckon I could solve the sync'ing problem with a bit of script. However I'm still keen to get into Eclipse because there is so much development clout behind it. Hopefully by the time VS2010 becomes my baseline someone else would have already written the GCC integration and I'll get another free ride :-)
Subscribe to:
Post Comments (Atom)
Thanks for the namecheck Chris. :)
ReplyDeleteGCC has been integrated into Visual Studio variants (AVR Studio 5.0 uses GCC, and of course there is VisualGDB), so it's certainly possible. Unfortunately as these are closed source projects you can't learn much from them other than it's doable by a somewhat smaller company than Intel (I've not seen any sample VS C++ language services, which is the obvious starting point).
By coincidence, we've been doing some tests with the Intel compiler in VS2010 this week, and the integration is far slicker than it was in VS2008. In VS2010 and VS2012, third party compilers such as ICL.EXE (the Intel compiler) show up as a user selectable toolchain in the project properties, so it is definitely getting easier.
However, as far as I know it is still a pretty complex thing to get right though (I've never tried it, but if I had the time and co-conspirators...). Remember you potentially need to not only interface to the compiler, but provide a COM based UI to configure it (messy).
There are some of course other ways to achieve the same aim without mucking about with VS language services - for example, writing a wrapper around GCC which emulates CL.EXE (I think someone has done that already), or building with an external compiler from VS using a makefile. /USEENV is another trick that springs to mind - you can even use that one to access a later compiler in an earlier version of Visual Studio.
Although they all seem like a bit of a bodge to me, if you find a way that works for you I'd say go for it (and write up what you find afterwards!).
P.S: Your blog captchas are terribly hard to get right. It took me 4 attempts.
ReplyDelete