Hello!

Sorry for long delay in the reply, I saw your post some time (apparently a month) ago, and figured to drop few words about my experiences about the matter.

The cleanest way according to my experiences is to simply wrap the cl.exe and link.exe and handle the custom builds there, as you suggest in your post. Few things to take into consideration are:

1. Decide whether you want to use "permanent" wrapping or try do swap in and out the wrappers when required. Permanent wrapping could use the command line parameter or some registry/file key of a user to determine when to use the custom call. When reverting back to the original cl.exe and link.exe, be sure that your environment (environment variables, paths and stuff like that) are intact of what they were when your wrapper was called.

By intact I mean, that the Visual Studio relevant info is proper (see below on the wrapping). At least when starting the process with .NET libraries, the environment passed over from the wrapper by default.

2. Depending of the 3rd party tools, it is likely that you have to clean up and reformat the command line tool output. You likely can get rid of the 90% of the issues with simple .NET regexping, by formatting the warning/error and alike messages to the Visual Studio format.

Note: some portions of VS command line tools use environment variables for communicating with Visual Studio for various matters. I don't recall on top of my head, what the variables are, but you'll find them by examining the environment variables that are passed to the cl.exe for example. If you don't remove these (or reroute to your own), some messages will bypass the standard output and thus you cannot reformat them.

This is the easiest way to get started with the issue, and leaves a lot of freedom for customization (that also will work on command line builds for macro/batch builds).

Of course the entire subject is much broader than these few points, but they should get you on at least one solid track that will get you to the goal (unless of course you already implemented it, no thanks to this month-late reply).

Best of year 2007,

Kalle

Got a fair bit of it implemented, but still have big one anoying problem, I'm trying to figure out how to let it do small rebuilds, i.e. only compiliing files that have changed. VS2005 seems to handle this in a *.idb (VC++ Minimum Rebuild Dependency File) which doesn't appear to have a documented format and appears to be an evil binary monstrosity, I figured I could use the same approach as old make file systems comparing the *.obj file last modified date/time with that of its source files (i.e. rebuilding it if one ofit's source files had been modified since the last time the obj was built) but I've found that the obj files seem to disapear when my cl.exe is called, does anyone know if this is VS2005 deleting the Obj files before compiling or something,

Or can anyone suggest a better way of limiting which files are rebuilt to only those that needto be..

Thanks.

Hi Guardian,

if you want cl.exe spit out some object files you have to use the /Fo compiler option, for the minimal rebuild /Gm is needed. /Gm acts as the classical makefile approach would (only files in need are rebuild). I think I remember that an appropriate .idb file is generated for this purpose.

Hope that helps...