incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject stdcxx-13 - Windows configration (was: Re: [Fwd: notes on the stdcxx configuration process])
Date Wed, 24 Aug 2005 02:31:39 GMT
[Moving a private discussion of stdcxx-13 to the list]

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 <removethistoexecuteSCRIPT> tag and registration
> ??>> 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.


> 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.

View raw message