views:

22

answers:

1

I've inherited some C99 code that I'm planing on reusing in a C++-centric solution. Unfortunately, even Microsoft's latest compiler has virtually no support for non-trivial C99 features.

The code in question has been tested to death and I'd rather not go through the trouble of rewriting it in C++. This means that in order for me to reuse the code verbatim I'll have to rely on a conforming 3rd-party compiler.

After looking around, it appears that the nicest way for me to integrate this code is by adding a "Makefile Project" to my solution. Only one problem. It seems like it is now my responsibility to keep the "Build Command Line" property synchronized with the files that I add to the project through Visual Studio.

At first glance, I couldn't find a way to get a list of files in my project through the usual Visual Studio $()-style macros. I could always write a shell script that would enumerate *.c files in my source tree and pass their paths to the 3rd-party compiler. However, I kind of expected that Visual Studio would do at least that part of the work for me since it already has this information in the relevant *.vc[x]proj file.

It is very unlikely that I'll need to add any new source files to this project, but still, manual synchronization (i.e., without a script) of this sort seems rather fragile to me.

What are my options besides writing a helper script?

A: 

From Hans Passant:

"Makefile project" means what it says, there needs to be another 'agent' that's responsible for the dependencies. Like a make file. Rule files can help you select another build tool but that's kinda broken right now in VS2010. Leverage the original tool that built this C99 code, run it from the makefile project.

kj53r
Seems like I can only accept this in ~2 days... Any super user welcome to mark this as answered.
kj53r