Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 85112 invoked from network); 6 Dec 2006 15:28:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Dec 2006 15:28:15 -0000 Received: (qmail 65633 invoked by uid 500); 6 Dec 2006 15:28:24 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 65623 invoked by uid 500); 6 Dec 2006 15:28:24 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 65610 invoked by uid 99); 6 Dec 2006 15:28:22 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Dec 2006 07:28:22 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Dec 2006 07:28:11 -0800 Received: from qxvcexch01.ad.quovadx.com (qxvcexch01.ad.quovadx.com [192.168.170.59]) by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id kB6FRiJg000864 for ; Wed, 6 Dec 2006 15:27:44 GMT Received: from [127.0.0.1] ([10.70.10.24]) by qxvcexch01.ad.quovadx.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 08:28:15 -0700 Message-ID: <4576E171.10409@roguewave.com> Date: Wed, 06 Dec 2006 08:27:45 -0700 From: Martin Sebor Organization: Rogue Wave Software User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: duplicate error message in Windows builds References: <4575AA8E.9050602@roguewave.com> <4575AC8B.6040103@roguewave.com> <4575B40D.1020308@roguewave.com> <4575BAA8.7040301@roguewave.com> <4575F9F3.8060508@roguewave.com> In-Reply-To: <4575F9F3.8060508@roguewave.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Dec 2006 15:28:15.0782 (UTC) FILETIME=[26386460:01C7194B] X-Virus-Checked: Checked by ClamAV on apache.org 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