incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Ostapenko" <>
Subject Re: stdcxx-13 - Windows configration (was: Re: [Fwd: notes on the stdcxx configuration process])
Date Wed, 24 Aug 2005 12:31:04 GMT
Hello, Martin!
You wrote to <> on Wed, 24 Aug 2005 06:31:39 

 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.

 MS> I was hoping there would be a way to do it from within the project.
 MS> I might have been overly optimistic. If there isn't, of if it isn't
 MS> portable across different versions of Visual Studio (VS), the script

I do not know any way to pass options used in a project to an external 
script. Possible way is to parce project file and get them from it but it 
will be definetely not portable between different VS versions.

 MS> that generates the VS Solution and Projects (and populates the
 MS> Configurations of each compiler with the appropriate set of compiler
 MS> and linker options from the compiler's .config file) should also
 MS> generate this file. However it's done it's imperative that there

No, this file can not be generated. It is an origin where 
compiler/linker/librarian options are being taken from. May be it was just a 
wrong analogy  with .config files (I have got an expression from makefiles 
that .config files play the same role).

 MS> be one central file with the set of options for each compiler.
 MS> Maintaining more than one would surely lead to errors.

That is how it was originally organized. Compiler options where placed in 
the configure.wsf. However Liviu insisted on splitting options into separate 
files. I could return them back if needed.

 ??>> A number of Visual Studio
 ??>> projects shall be created for all supported Visual Studio versions.

 MS> If you mean that they will be created by hand I fear it would be both
 MS> too tedious and error-prone. Assuming we have three versions of VS to

I can not agree. For the first time solution for VS6 could be created. All 
others could be obtained by autoconverting it to a new format and may be 
minor subsequent fixes.

 MS> maintain (6.0, 7.1, and 8.0), each time a new test is added we will
 MS> have to remember to update three VS Solutions and add the test to
 MS> each one of them. Each time we decide to change a compiler option

What test are you talking about? Configuration ones or unit/integration?

 MS> common to all two or more versions of the compiler we will have to
 MS> update two or more sets of Solutions, hundreds of projects each.

 MS> It's important for the Solution to be able to automatically pick up
 MS> new Projects (such as new config tests, examples, tests, etc.). It's

Well, that is the problem (except config tests which are beyond the 

 MS> also important that there be an easy way to add/change/remove options
 MS> across all projects in the Solution.

Could you explain why it could be need for? In a single solution it could be 
easily done from Visual Studio.

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

 MS> I agree with this part. A single configuration script shared by all
 MS> versions of VS and all compilers on Windows (except perhaps those
 MS> targeting UNIX-like environments such as Cygwin). It should be
 MS> possible to invoke the script independently of VS from the command
 MS> line but it can also be included as a VS Project in the stdcxx VS
 MS> Solution (using VS 7.1 terminology). All other Projects within the
 MS> Solution will depend on the output of the script (the config file),
 MS> so that building the library will automatically create or update
 MS> the config file as necessary.

But that will not work if we are going to generate solution files.

 ??>> Your design will require running first steps
 ??>> from a command line.

 MS> It doesn't matter how the script is invoked, it can be made nearly
 MS> transparent to the user (with icons, shortcuts, etc).

Well, common sequence will be the following:
1) Running cmd.exe to open command line.
2) Running vcvars32.bat (or similar file to setup path and includes).
3) Running script that will configure library and produce solution file.
4) Opening solution.

Only there user will be able to work with a solution. Sequence does not look 
completely transparent.

 ??>> The same configuration script could be later reused
 ??>> for compilers that can not be integrated into Visual Studio (like PSDK
 ??>> compilers).

 MS> 100% agreed. As I said, there should be just one general configuration
 MS> script that either reads the contents of the original .config file or
 MS> the contents of some preprocessed version of it spit out by the script
 MS> that generates the Solution.

 MS> As for compilers w/o the IDE, I was (perhaps again naively) hoping
 MS> that the IDE is available everywhere. If that's not the case, I would
 MS> still like to focus on the IDE first and handle those w/o it as a
 MS> special case.

That is definetely not the case. PSDK compilers do not have IDE and even 
could not be integrated into existing VS IDE.

With best wishes,
Alex Ostapenko. 

View raw message