incubator-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 Thu, 25 Aug 2005 15:04:27 GMT
Alex Ostapenko wrote:
> Hello, Martin!
> You wrote to <stdcxx-dev@incubator.apache.org> on Thu, 25 Aug 2005 
> 00:52:00 +0400:
> 
[...]
> I mean that vc_conf.js file is the msvc.config. Although it looks like 
> it will require complete rewriting (see below).

Most definitely.

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

I hope not. All the UNIX .config files have the same structure, so
I'm not sure I see a reason why the Windows .config files couldn't
do the same.

> Morevover solution representation of 
> options is completely different from compilers command line options.

That shouldn't be a problem as long as our representation is
expressive enough to accommodate the other two.


> So, 
> besides the structure itself we will have to write converters from one 
> representation (probably solution one) to another.

It seems to me that starting with the .config representation and
generating (or "converting" it into) the representation appropriate
for the Solution of each version of VS should be the way to go, no?

> Options handling may 
> easily become most complex part of the script.

That's likely. Look at the GNUmakefiles -- the most complex part it
the handling of compiler and linker options.

> And addition of a new 
> compiler may become a nightmare.

Not if we do it right. Adding a new compiler option to any UNIX
compiler is a snap.

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

Not if the script picks it up automatically from the directory tree,
just like the UNIX infrastructure does. There's nothing you have to
do on UNIX to get the infrastructure to recognize that another test
(unit or config) or example has been added. It just happens because
the makefiles look for any .cpp files in the expected locations.

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

Let's start with one and see where we get.

> So, changes in options for VS6 solution probably will require MANUAL 
> changes in options for other solutions.

We must avoid that by having single repository of compiler options
for each compiler.

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

There may not be any need for conditions yet because the only
version it handles is 7.1 (right?). As soon as we add other
versions or platforms (such as IA64) there will likely be.

Incidentally, keep in mind that this file will become much more
complex as soon as you start using it for more than just the config
tests (i.e., to build the library, the example programs, the test
driver library which links with the stdcxx library, and the unit
tests which link with both).

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

The two steps need to be separate. We don't want to have to regenerate
the whole solution only to reconfigure the library (e.g., after making
a _temporary_ change to the compiler options in the Solution, or after
making a modification to a config test),

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

That's still up to them. I.e., not our problem :) We start out by
assuming that the compiler is set up and ready to use.

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

Not even with the assumption above?

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

Maybe not. It's just a possibility (see The Demo).

Martin

Mime
View raw message