incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: duplicate error message in Windows builds
Date Wed, 06 Dec 2006 15:27:45 GMT
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?


View raw message