Martin Sebor wrote: [...]
There's no point in continuing to try to build all the downstream projects after a required dependency fails. I thought even VisualStudio understood that. Doesn't the GUI behave that way?
I ran a test build through the GUI, and I observed the same behavior as in the the command line builds, mainly that the process doesn't short circuit. I've asked one of our coworkers who works with Visual Studio, and he also was unable to find any switches or solution options to alter this behavior. He did note that makefile based projects will terminate the build process when an entire solution is built.
In my opinion, the generated build_foo.bat script should be altered such that it builds the .configure, .stdlib, .stdlib_examples, .rwtest, .stdlib_tests and .stdlib_locales and .stdlib_localetests projects in a sequential manner, checking the return code from building the .configure, .stdlib and .rwtest projects.
There are a couple related changes that I would like to see as improvements. The first change is to the behavior of the stdlib_examples, .stdlib_tests and .stdlib_localetests targets. When these targets are built, they run the generated executables. To me, it would make more sense if they were run when the target was run, rather than built. A potential problem I see with making this change is that devenv might try to run all the dependencies prior to running the target.
The second change I would like to see is in how the exec utility is used within these targets. The utility is designed to run multiple targets in a single invocation, and I believe it is more efficient to do so, rather than calling it with a single target for every executable in the set.
--Andrew Black
Martin
