incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Ostapenko" <alex...@moscow.vdiweb.com>
Subject Re: stdcxx-13 - Windows configration
Date Thu, 25 Aug 2005 13:14:02 GMT
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 a separate solution just 
to launch two scripts from it.

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

 MS> Here's how I picture this to work on Windows:

 MS> An icon somewhere in the file system (such as a shortcut in the Start
 MS> Menu or in a directory) that the typical GUI user will click or double
 MS> click on to get going for the first time. (A user who works on the
 MS> command line will simply execute the file).

As I have already said earlier no shorcut could be created that will do 
first two steps automatically.

With best wishes,
Alex Ostapenko. 


Mime
View raw message