stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: stdcxx-13 - Windows configration
Date Wed, 24 Aug 2005 20:52:00 GMT
Alex Ostapenko wrote:
[...]
> 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.

Probably not. Which means that configure.bat needs to get the options
from somewhere else. Since they must be centralized, it can either
read them from the one central location (let's call the one for MSVC
msvc.config) or from somewhere else. Since there can be only one
central location the "somewhere else" would have to be generated
from msvc.config.

> 
[...]
> 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).

What I meant was that the generate.bat script that populates the
stdcxx Solution could generate it from msvc.config.

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

No, I don't think you should. I agree with Liviu's approach.

The options for each compiler need to be in one central place. That's
a requirement. They will most likely need to be organized in groups
along the same lines as in the other .config files.

The configuration script needs to be general so that it can be used
for different compilers with different command line options. That's
also a requirement.

Otherwise we would end up with a bunch of scripts, one for each
compiler, every one of which containing the exact same logic but
different options. Now imagine the nightmare of wanting to support
one version of Intel C++ on top VS 6 and VS 7. We'd also have two
different scripts each with the same set of options that we'd have
to carefully keep in synch...

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

This is not an option unless we solve the two fundamental problems:
1. compiler and linker options for each compiler in the same place,
2. adding a test, example, or any other component to stdcxx requires
    at most one additional change (and preferably none).

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

I was talking about unit tests. (For the sake of clarification:
test = unit test, config[uration] test = configuration test).

When a developer whose environment is VS 7.1 adds a new unit test,
I don't want them to have to remember to change more than one place
in the stdcxx build infrastructure for that test to become part of
the test suite for automated testing. Ideally, they would have to
do nothing else beyond adding the test to 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.

If compiler and linker options can be easily modified across all
Projects in a Solution it removes a part of one of the problems
with this approach, but it doesn't solve the whole problem. The
other part is having multiple Solutions for different versions
of VS, all of which currently share the same compiler and linker
options. Changes made to the VS6 Solution will also need to be
made in the Solution for VS7, and if VS8 is incompatible, in the
one for VS8 as well.

It is *really* important that we not duplicate the compiler and
linker options. Look at gcc.config and all the conditionals in it
to get an appreciation of what it would involve to duplicate those
options in two or more places and to keep them in synch. This
complexity is only going to increase with new versions of compilers
and as we add new platforms.

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

What exactly will not work and why?

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

The first 2 steps can be invoked from step 3. In fact, if the script
is a batch file step 1 is implicit. Running vcvars32.bat is usually
the user's responsibility in any case. It's okay to make the assumption
that the compiler is correctly set up.

> 4) Opening solution.

...and the last step can be invoked last from the script. If the two
scripts to generate the final Solution and to configure the library
are themselves a VS Solution and a VS Project, respectively, it's
all just one step.

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

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

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

This will fire up a sequence of events the result of which will be a VS
IDE populated with a Solution with the stdcxx library, examples, etc.
loaded in it as Projects, ready to build (or first configure and then
build). It could also work the way The Demo does, i.e., that the initial
Solution will contain just a single Project that, when activated, will
populate the rest of the Projects in the Solution.

Passing arguments to the file behind the icon will let us also build
any or all of the Projects withing the Solution, and even run the
examples and tests to produce output for automated testing.

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

Well, we'll just have to come up with an alternative for the SDK then.
I'm not terribly concerned about it at this point. We'll cross that
bridge when we get to it. Right now I would like to see a prototype
for VS 7.1 using the IDE.

Martin

Mime
View raw message