Hello, Martin!
You wrote to stdcxx-dev@incubator.apache.org on Thu, 25 Aug 2005 00:52:00
+0400:
MS [...]
?? 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 What I meant was that the generate.bat script that populates the
MS stdcxx Solution could generate it from msvc.config.
I mean that vc_conf.js file is the msvc.config. Although it looks like it
will require complete rewriting (see below).
MS The options for each compiler need to be in one central place. That's
MS a requirement. They will most likely need to be organized in groups
MS along the same lines as in the other .config files.
Things are becoming very interesting here. To be able to generate solutions
we will probably have to create a unique complex structure for each
compiler/linker/librarian. Morevover solution representation of options is
completely different from compilers command line options. So, besides the
structure itself we will have to write converters from one representation
(probably solution one) to another. Options handling may easily become most
complex part of the script. And addition of a new compiler may become a
nightmare.
MS When a developer whose environment is VS 7.1 adds a new unit test,
MS I don't want them to have to remember to change more than one place
MS in the stdcxx build infrastructure for that test to become part of
MS the test suite for automated testing. Ideally, they would have to
MS do nothing else beyond adding the test to the Solution.
They will have at least to add a new test to a solution generation script.
MS If compiler and linker options can be easily modified across all
MS Projects in a Solution it removes a part of one of the problems
MS with this approach, but it doesn't solve the whole problem. The
MS other part is having multiple Solutions for different versions
MS of VS, all of which currently share the same compiler and linker
MS options. Changes made to the VS6 Solution will also need to be
MS made in the Solution for VS7, and if VS8 is incompatible, in the
MS one for VS8 as well.
I am afraid it will be too hard to implement options shared between
different solutions because of different representation of these options in
different solutions formats.
So, changes in options for VS6 solution probably will require MANUAL changes
in options for other solutions.
MS It is *really* important that we not duplicate the compiler and
MS linker options. Look at gcc.config and all the conditionals in it
MS to get an appreciation of what it would involve to duplicate those
MS options in two or more places and to keep them in synch. This
MS complexity is only going to increase with new versions of compilers
MS and as we add new platforms.
In case of Microsoft compilers things could be much simplier. Just take a
look at vc_conf.js. There is no need for conditions here.
MS [...]
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.
MS What exactly will not work and why?
Probably I have misplaced the comment. Nevertheless, if we are going to
generate solution there will be no need to add configuration project to it.
Configuration could be done at a time of solution generation.
?? 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.
MS The first 2 steps can be invoked from step 3. In fact, if the script
No, they can not be. User could have multiple compilers on his PC and he
will need to choose correct vcvars32.bat.
MS is a batch file step 1 is implicit. Running vcvars32.bat is usually
MS the user's responsibility in any case. It's okay to make the assumption
MS that the compiler is correctly set up.
It was just to say that it will not be sufficient to click on one shortcut.
?? 4) Opening solution.
MS ...and the last step can be invoked last from the script. If the two
MS scripts to generate the final Solution and to configure the library
MS are themselves a VS Solution and a VS Project, respectively, it's
MS all just one step.
I do not think that it really make sense to create
