Hello, Martin!
You wrote to <stdcxx-dev@incubator.apache.org> on Wed, 24 Aug 2005 06:31:39
+0400:
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
solution).
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.
