Alex Ostapenko wrote:
[...]
??>> 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.
Yes, that's understood and considered an acceptable cost given the
relatively low frequency of incompatible VS releases.
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.
As I said, the two big problems I see with rolling the VS Solutions
by hand is the duplication of compiler and linker options between
the config script and the Solution, and the tedium of manually having
to add each new Project (i.e., ever new example, unit test, or locale)
to the Solution.
FWIW, I initially considered the manual approach as well but wound up
rejecting it due to these two problems. If you can find a way to solve
them I might reconsider my position.
Own VS converter could be used for that purposes.
That's an interesting idea that we should look into. Initially, let's
focus on VS 7.1. Once we have a working prototype we can investigate
the possible approaches for other versions.
??>> 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.
I know they have a way to convert VS Solutions or Projects to use
their compiler but I don't know the details. I'll leave it for you
to investigate :) (But again, let's get a prototype working for VS
7.1 first).
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.
Please look into the single Solution approach first. If it can't
be done, let's try this alternative.
??>> 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.
Yes, that is a tradeoff, but I think it's an acceptable one. The vast
majority of developers will be happy using the VS Solutions and Projects
since they have the whole IDE. Developers whose development environment
is the bare SDK with no IDE are, IMO, an insignificant minority (remote
builds on an SDK-only target should be possible from the IDE on an IDE
equipped host). That said, we will eventually have to come up with a
workaround for automated testing, but let's worry about it after we're
done with the IDE-based prototype.
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.
VS automation can be used to reload a Solution into it or add/remove
Projects from it (I have just seen an demo of this). But that wasn't
necessarily what I was talking about. The idea I was trying to
describe was a script, let's call it generate.bat, to generate the
VS Solution populated with a project to configure the library (call
it configure.bat), another to build the library (call it stdcxx.lib),
and one for each example program, unit test, utility program, and
locale. Generate.bat would be invoked first, with VS invoked next
on its result. An extension of this idea (now validated by the demo
I've just seen) is to have generate.bat be the only project of the
initially otherwise empty VS Solution. Invoking that Project would
populate the Solution with all the other Projects, all within the
same VS session.
??>> 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.
In our experience it is unacceptably high. Having a single database
of compiler options is a must.
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.
The Solutions will change on a regular basis. Every time a unit test
is added, the Solution will need to be updated. If we had just one
Solution, updating it manually wouldn't be a big deal, but with more
than one Solution likely, and with non-Solution approaches necessary
due to the absence of an IDE in the SDK, adding a test would require
a change in a number of places. It would then be quite easy for a
developer used to the IDE to forget to update one or all of the other
places (I've been there and done that :)
While I agree that compiler options change relatively infrequently,
the price of forgetting to change all the places where they are
duplicated is typically very high (think days of effort to find
out that a test is misbehaving in a mysterious way because the
library is misconfigured).
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.
But only for the one generated session. The change would be reverted
by regenerating the Solution during automated testing. This might be
elegantly dealt with by a VS automation script that would detect
a change to the compiler or linker options made to the Solution and
offer to make the corresponding change to the central database of
options.
Martin
