Including a VB project within a VC++ project

Question

I'm looking for some help with a dependency issue. In a nutshell, I've included a makefile project within a larger VC++ workspace, but the sub-project always rebuilds, even when it's not necessary.

The Details

I've inherited a large project that consists of several different modules, including a (primary) Visual C++ 6.0 executable and a smaller Visual Basic 6.0 DLL.

Today it's built manually, by launching each IDE and generating each component from its own environment. I'd like to turn this into a one-click build from within the VC++ IDE. (The end goal is to export the makefile, automate the entire process, and institute nightly builds.)

To this end, I've added a "Makefile" project to the VC++ workspace. The makefile builds the VB DLL by invoking the VB compiler from a command line.

The problem is that the VB project always rebuilds itself, adding several minutes to the build process. I suppose I could avoid this by adding all of the VB source files as dependencies, but this would likely turn into a maintenance problem, as it would require developers to update the VC++ workspace each time the VB component changes.

Is there a way to make the build process more selective, so VB runs only when the DLL needs to be rebuilt, short of adding every source file to the VC++ project as a dependency?

Thanks for your thoughts!

Answer 1

You could do the dependency scan yourself. Trigger the VB build only when any VB source file is newer than the build-output of the VB-build (where you can scan recursively using wild cards, i.e. no explicit configuration). You may need to additionally care for the references the VB project uses.

This of course needs some manual make-file writing. As VB6 seemingly does not support any dependency checking itself, I can't think of any purely IDE based solution (which does not require the double-bookkeeping you mentioned).

As you're just starting to implement nightly builds for a VB project, this seems to indicate that this project may be in development/maintenance for a longer time. This longer time itself may be an indication to port the VB project to VB.NET, which improves the build process for VB projects by quite a good margin.