Andrew Black wrote:
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.
Of course they will. That's the only thing that makes sense.
I have a hard time believing that not avoiding the building
of dependencies is by design. I wonder if the dependencies
among our projects are set up correctly. It would be helpful
to confirm this behavior in a small test case.
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.
That would make sense as a workaround if we can't get Visual
Studio to behave in a reasonable way. But it's not the ideal
solution since it increases the coupling between the script
and the infrastructure (the same is true on UNIX).
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.
We might need to have two separate projects for each set of
components (examples, tests, and locale tests): one to build
them all and another to run them.
Btw., the names of these projects should be stdcxx, not stdlib.
Farid, does this sound like a good approach to you?
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.
I agree. I would also like to see this change. Farid, what's
your opinion? Is it doable and reasonably easy?
Martin
