From stdcxx-dev-return-55-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Wed Aug 24 12:01:52 2005 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 96749 invoked from network); 24 Aug 2005 12:01:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 24 Aug 2005 12:01:52 -0000 Received: (qmail 41801 invoked by uid 500); 24 Aug 2005 12:01:52 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 41783 invoked by uid 500); 24 Aug 2005 12:01:52 -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 41769 invoked by uid 99); 24 Aug 2005 12:01:51 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Aug 2005 05:01:51 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of AlexeyO@moscow.vdiweb.com designates 195.210.189.132 as permitted sender) Received: from [195.210.189.132] (HELO mail.moscow.vdiweb.com) (195.210.189.132) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Aug 2005 05:02:08 -0700 Received: from alexeyo ([195.210.189.130]) by mail.moscow.vdiweb.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 16:01:44 +0400 Message-ID: <001801c5a8a3$986a5c10$89000b0a@moscow.vdiweb.com> From: "Alex Ostapenko" To: "Martin Sebor" , References: <430BE889.5020605@roguewave.com> Subject: Re: stdcxx-13 - Windows configration Date: Wed, 24 Aug 2005 16:01:43 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16 X-OriginalArrivalTime: 24 Aug 2005 12:01:44.0024 (UTC) FILETIME=[986B6D80:01C5A8A3] X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hello, Martin! You wrote to on Wed, 24 Aug 2005 07:24:57 +0400: ??>>>> What about VC 8 for x64 and IA64 platforms? Should they be MS> supported? ??>> MS>>> Eventually. I expect people (i.e., the stdcxx community) to want to MS>>> add other platforms as well (e.g., Como, Digital Mars, Watcom, etc.). ??>> ??>> Well, in this case the best option, as I have already said, would be ??>> using something like Boost.Build. Otherwise people will need to invent ??>> bicycles. MS> Relying on third party tools is not an option at this stage. OK. MS>>> Even if we don't need to immediately accommodate any of these MS> platforms MS>>> now we should try to be as flexible as possible in order to make MS> adding MS>>> new ones or changing existing ones straightforward. This also means MS>>> that there should be an easy way of adding, removing, or changing an MS>>> existing compiler or linker option across all "projects" in the MS>>> "solution" (I hope I'm using the correct Visual Studio terminology MS>>> here). ??>> ??>> I am not sure that Visual Studio terminology is applicable here. ??>> Visual Studio does not allow adding, removing or changing compilers ??>> without writing special Visual Studio extensions. MS> That's where the other script to generate the VS Solution will come MS> in handy :) I am afraid that generation solutions for VS will not be an easy task itself. All VS version have different project files structures (may be except VS 7 and VS 7.1 those have similar project file format). Also, adding support for a new VS version will require significant cahnges in a script. I think it would be better to create required project files "by hands" from withing an IDE and use them as they are. This will also minimize efforts on creating project files for a newer version of Visual Studio. Own VS converter could be used for that purposes. ??>> What do you mean by "extend Platform" here? As I have already said ??>> Visual Studio does not allow simple extension of its ??>> Platform/Configuration model. MS> There's no way to add a fourth Platform and beyond? There is a way MS> to add another compiler, isn't there? (I sure hope so, otherwise MS> we might have quite a bit more work to do than I thought). By At least no simple way. AFAIK, adding own compiler requires writing a VS add-on. Also, I have not seen any addons adding anything to Platform/Configuration options. MS> extending Platform I meant adding Intel C++/Win32, Intel C++/Win64, MS> and Intel C++/Win64 x64 to what's already there for MSVC. If there >From reviews on the Intel site I have got an impression that only Intel C++/Win32 could be integrated into VS. x64 compiler seems to be command line only. Also, I have not seen anything about ICC for Itanium. Only for x64/EMT64. Also, I do not know how ICC 32 integrates into VS. May be it just has the same name (cl) and simply should be placed before MS cl in the path. MS> is no way to do that, we might just have to generate a different MS> solution for Intel C++. That is probably what we will have to do. ??>> Many teams prefer command line build for this purposes. MS> So do we. Unfortunately (or perhaps thankfully), the existing Rogue MS> Wave build infrastructure (RCB) is not part of stdcxx so we cannot MS> rely on it. The goal of this exercise is to get both the convenience MS> of the VS Solutions and Project as well as the flexibility of the MS> command line, ideally in one neat package. Having VS solutions we will have command line build for free. But other compilers (like PSDK ones) will require writing special build scripts for them. MS> [...] MS>>> By implementing the Visual Studio projects/solution, I would like MS>>> to provide a convenient development environment for *contributors* MS>>> to the stdcxx project. I'm less concerned with the *users* of the MS>>> library since they only rarely build it, but if we do it the "right MS>>> way" they might still benefit by being offered an example of a robust MS>>> development framework on which they could model the development MS>>> environment for their own applications. ??>> ??>> Well, that is the reason. However developers of the library could run ??>> configuration script only once and then they could use a solution that ??>> does not include configuration steps (Is that what you have talked ??>> about in the previou e-mail?). MS> My idea is that developers would generate the Solution with the MS> configuration script as one of its Projects. They would configure MS> (and reconfigure after changes to config tests) the library within MS> the Solution simply by right clicking on the Project and selecting MS> the Build menu option (at least I think that's how it's done). That will not work. If you are going to generate solution you will have to close Visual Studio, generate solution from a command line and then open it in a Visual Studio. ??>> It will be much harder that simply create a set of solutons from ??>> Visual Studio. I think it would be better to create a solution and ??>> then describe corresponding compiler, linker and librarian options in ??>> the configuration script. MS> But then we'd have to maintain the compiler options in two different MS> places: one in each Project within the Solution and the other in the MS> configuration script. The risk of the two diverging after some time MS> is just too great (we have quite a bit of experience with this MS> problem and its conseuqences are usually really nasty). That is right. But I do not think that risk is really high there. Number of options that could really cause discrepances between tests options and options for library is really small (just a few optimization options and a few runtime options). And I see no problems to make a contract on changing them in both places simultaneously. Also, in general usage both config script and solutions will be immutable, so no discrepances should occur. Another point is that nothing could prevent user from changing options in generated solution. And consequences could be the same as in the previous case. MS> The language doesn't matter. It's the concept that does. Let me MS> forward it to you privately so you can get an idea of how it MS> works and what the output is. I think Andrew implemented some MS> interesting things that might help you better understand what MS> I'm looking for. OK. With best wishes, Alex Ostapenko.