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 Wed, 24 Aug 2005 12:01:43 GMT
Hello, Martin!
You wrote to <stdcxx-dev@incubator.apache.org> on Wed, 24 Aug 2005 07:24:57 
+0400:

 ??>>>> What about VC 8 for x64 and IA64 platforms?  Should they be
 MS> supported?
 ??>>
 MS>>> Eventually. I expect people (i.e., the stdcxx community) to want to
 MS>>> add other platforms as well (e.g., Como, Digital Mars, Watcom, etc.).
 ??>>
 ??>> Well, in this case the best option, as I have already said, would be
 ??>> using something like Boost.Build. Otherwise people will need to invent
 ??>> bicycles.

 MS> Relying on third party tools is not an option at this stage.

OK.

 MS>>> Even if we don't need to immediately accommodate any of these
 MS> platforms
 MS>>> now we should try to be as flexible as possible in order to make
 MS> adding
 MS>>> new ones or changing existing ones straightforward. This also means
 MS>>> that there should be an easy way of adding, removing, or changing an
 MS>>> existing compiler or linker option across all "projects" in the
 MS>>> "solution" (I hope I'm using the correct Visual Studio terminology
 MS>>> here).
 ??>>
 ??>> I am not sure that Visual Studio terminology is applicable here.
 ??>> Visual Studio does not allow adding, removing or changing compilers
 ??>> without writing special Visual Studio extensions.

 MS> That's where the other script to generate the VS Solution will come
 MS> in handy :)

I am afraid that generation solutions for VS will not be an easy task 
itself. All VS version have different project files structures (may be 
except VS 7 and VS 7.1 those have similar project file format). Also, adding 
support for a new VS version will require significant cahnges in a script. I 
think it would be better to create required project files "by hands" from 
withing an IDE and use them as they are. This will also minimize efforts on 
creating project files for a newer version of Visual Studio. Own VS 
converter could be used for that purposes.

 ??>> What do you mean by "extend Platform" here? As I have already said
 ??>> Visual Studio does not allow simple extension of its
 ??>> Platform/Configuration model.

 MS> There's no way to add a fourth Platform and beyond? There is a way
 MS> to add another compiler, isn't there? (I sure hope so, otherwise
 MS> we might have quite a bit more work to do than I thought). By

At least no simple way. AFAIK, adding own compiler requires writing a VS 
add-on. Also, I have not seen any addons adding anything to 
Platform/Configuration options.

 MS> extending Platform I meant adding Intel C++/Win32, Intel C++/Win64,
 MS> and Intel C++/Win64 x64 to what's already there for MSVC. If there

>From reviews on the Intel site I have got an impression that only Intel 
C++/Win32 could be integrated into VS. x64 compiler seems to be command line 
only. Also, I have not seen anything about ICC for Itanium. Only for 
x64/EMT64. Also, I do not know how ICC 32 integrates into VS. May be it just 
has the same name (cl) and simply should be placed before MS cl in the path.

 MS> is no way to do that, we might just have to generate a different
 MS> solution for Intel C++.

That is probably what we will have to do.

 ??>> Many teams prefer command line build for this purposes.

 MS> So do we. Unfortunately (or perhaps thankfully), the existing Rogue
 MS> Wave build infrastructure (RCB) is not part of stdcxx so we cannot
 MS> rely on it. The goal of this exercise is to get both the convenience
 MS> of the VS Solutions and Project as well as the flexibility of the
 MS> command line, ideally in one neat package.

Having VS solutions we will have command line build for free. But other 
compilers (like PSDK ones) will require writing special build scripts for 
them.

 MS> [...]
 MS>>> By implementing the Visual Studio projects/solution, I would like
 MS>>> to provide a convenient development environment for *contributors*
 MS>>> to the stdcxx project. I'm less concerned with the *users* of the
 MS>>> library since they only rarely build it, but if we do it the "right
 MS>>> way" they might still benefit by being offered an example of a robust
 MS>>> development framework on which they could model the development
 MS>>> environment for their own applications.
 ??>>
 ??>> Well, that is the reason. However developers of the library could run
 ??>> configuration script only once and then they could use a solution that
 ??>> does not include configuration steps (Is that what you have talked
 ??>> about in the previou e-mail?).

 MS> My idea is that developers would generate the Solution with the
 MS> configuration script as one of its Projects. They would configure
 MS> (and reconfigure after changes to config tests) the library within
 MS> the Solution simply by right clicking on the Project and selecting
 MS> the Build menu option (at least I think that's how it's done).

That will not work. If you are going to generate solution you will have to 
close Visual Studio, generate solution from a command line and then open it 
in a Visual Studio.

 ??>> It will be much harder that simply create a set of solutons from
 ??>> Visual Studio. I think it would be better to create a solution and
 ??>> then describe corresponding compiler, linker and librarian options in
 ??>> the configuration script.

 MS> But then we'd have to maintain the compiler options in two different
 MS> places: one in each Project within the Solution and the other in the
 MS> configuration script. The risk of the two diverging after some time
 MS> is just too great (we have quite a bit of experience with this
 MS> problem and its conseuqences are usually really nasty).

That is right. But I do not think that risk is really high there. Number of 
options that could really cause discrepances between tests options and 
options for library is really small (just a few optimization options and a 
few runtime options). And I see no problems to make a contract on changing 
them in both places simultaneously. Also, in general usage both config 
script and solutions will be immutable, so no discrepances should occur.
Another point is that nothing could prevent user from changing options in 
generated solution. And consequences could be the same as in the previous 
case.

 MS> The language doesn't matter. It's the concept that does. Let me
 MS> forward it to you privately so you can get an idea of how it
 MS> works and what the output is. I think Andrew implemented some
 MS> interesting things that might help you better understand what
 MS> I'm looking for.

OK.

With best wishes,
Alex Ostapenko.


Mime
View raw message