From stdcxx-dev-return-53-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Wed Aug 24 02:29:56 2005 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 85086 invoked from network); 24 Aug 2005 02:29:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 24 Aug 2005 02:29:56 -0000 Received: (qmail 67818 invoked by uid 500); 24 Aug 2005 02:29:56 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 67800 invoked by uid 500); 24 Aug 2005 02:29:55 -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 67787 invoked by uid 99); 24 Aug 2005 02:29:55 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Aug 2005 19:29:55 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [12.17.213.84] (HELO bco-exchange.bco.roguewave.com) (12.17.213.84) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Aug 2005 19:30:12 -0700 Received: from [10.70.3.113] (10.70.3.113 [10.70.3.113]) by bco-exchange.bco.roguewave.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id NNYTQ7H8; Tue, 23 Aug 2005 20:29:30 -0600 Message-ID: <430BDC0B.8090504@roguewave.com> Date: Tue, 23 Aug 2005 20:31:39 -0600 From: Martin Sebor User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org CC: Alex Ostapenko Subject: stdcxx-13 - Windows configration (was: Re: [Fwd: notes on the stdcxx configuration process]) References: <43023D85.6090600@roguewave.com> <020b01c5a31f$7ca3cb30$89000b0a@moscow.vdiweb.com> <43035C3C.9070408@roguewave.com> <029701c5a408$89066b00$89000b0a@moscow.vdiweb.com> <4304B490.7010000@roguewave.com> <000801c5a4a1$d76d1f70$89000b0a@moscow.vdiweb.com> <430610A0.2060301@roguewave.com> <002901c5a70f$eea1b410$89000b0a@moscow.vdiweb.com> <430A8434.3030506@roguewave.com> <001401c5a7c3$73504970$89000b0a@moscow.vdiweb.com> In-Reply-To: <001401c5a7c3$73504970$89000b0a@moscow.vdiweb.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [Moving a private discussion of stdcxx-13 to the list] http://issues.apache.org/jira/browse/stdcxx-13. Alex Ostapenko wrote: [...] > ??>> OK, I have moved VC settings out of configure.wsf to the vc_conf.js. > ??>> However, adding new compilers will require modifications of > ??>> configure.wsf (new tag and registration of > ??>> a new compiler in the "compilers" collection should be added). > > MS> Which file is vc_conf.js supposed to be the equivalent of? If it's > MS> one of the .config files (such as gcc.config) then I don't think > MS> the file is necessary at this stage unless it's generated. > > Yes, it is an equivalent of a .config file. But I do not understand how > it could be generated. This file specifies options for a compiler, > linker and librarian and I see no way to find them out automatically. I was hoping there would be a way to do it from within the project. I might have been overly optimistic. If there isn't, of if it isn't portable across different versions of Visual Studio (VS), the script that generates the VS Solution and Projects (and populates the Configurations of each compiler with the appropriate set of compiler and linker options from the compiler's .config file) should also generate this file. However it's done it's imperative that there be one central file with the set of options for each compiler. Maintaining more than one would surely lead to errors. > > MS> Here's how I think it should work: > > I had completely different picture in mind. It doesn't seem all that different to me :) I think we're pretty much on the same page except for a few details. > A number of Visual Studio > projects shall be created for all supported Visual Studio versions. If you mean that they will be created by hand I fear it would be both too tedious and error-prone. Assuming we have three versions of VS to maintain (6.0, 7.1, and 8.0), each time a new test is added we will have to remember to update three VS Solutions and add the test to each one of them. Each time we decide to change a compiler option common to all two or more versions of the compiler we will have to update two or more sets of Solutions, hundreds of projects each. It's important for the Solution to be able to automatically pick up new Projects (such as new config tests, examples, tests, etc.). It's also important that there be an easy way to add/change/remove options across all projects in the Solution. > Each > of this projects will call configuration script as a custom build step > passing some parameters (like compiler name, test or debug and shared or > static) to it. Script will all tests and create config.h file. Than > build will continue to build library and other tools. I agree with this part. A single configuration script shared by all versions of VS and all compilers on Windows (except perhaps those targeting UNIX-like environments such as Cygwin). It should be possible to invoke the script independently of VS from the command line but it can also be included as a VS Project in the stdcxx VS Solution (using VS 7.1 terminology). All other Projects within the Solution will depend on the output of the script (the config file), so that building the library will automatically create or update the config file as necessary. > Such design will > allow library building either from Visual Studio or from command line > (it was a requirement). The requirement was only to be able to invoke VS from the command line and have it build the library (and other components). We didn't actually consider the case of a standalone compiler with no IDE. We might need to accommodate that case as well but let's focus on the IDE case first. > Your design will require running first steps > from a command line. It doesn't matter how the script is invoked, it can be made nearly transparent to the user (with icons, shortcuts, etc). > The same configuration script could be later reused > for compilers that can not be integrated into Visual Studio (like PSDK > compilers). 100% agreed. As I said, there should be just one general configuration script that either reads the contents of the original .config file or the contents of some preprocessed version of it spit out by the script that generates the Solution. As for compilers w/o the IDE, I was (perhaps again naively) hoping that the IDE is available everywhere. If that's not the case, I would still like to focus on the IDE first and handle those w/o it as a special case. > > MS> 1. Run a script to generate Visual Studio solution and projects. > MS> This stage generates compiler and linker options for all the > MS> supported compilers and the build configurations (build types). It might also need to generate a file for each compiler/configuration combination with the appropriate compiler and linker options as input to the configuration script. Martin > MS> The input to this stage is a file, say msvc.config, with a > MS> structure and contents analogous to the other .config files > MS> (such as gcc.config). The additional input is the equivalent > MS> of TOPDIR (the top of the source tree) and BUILDDIR (the root > MS> of the build directory), and the version of Visual Studio. > > MS> 2. Configure the library for a given compiler, target, and build > MS> type (Configuration and Platform), based on command line options > MS> passed to Visual Studio. > MS> This stage is one of the generated projects under the stdcxx > MS> solution generated in (1). All other projects have the output > MS> of this project (i.e., the file config.h) as a dependency. This > MS> stage needs to find out what the selected Configuration and > MS> Platform are in order to get the right compiler and linker > MS> options for the config tests. > > MS> 3. Build the library with the config.h file generated in stage (2). > > MS> 4. Compile the remaining stdcxx components and link each with the > MS> library produced in stage (3). > > With best wishes, > Alex Ostapenko.