Alex Ostapenko wrote:
> Hello, Martin!
> You wrote to <[EMAIL PROTECTED]> on Mon, 22 Aug 2005 17:50:36
> -0600:
>
> ??>> We need to build on following platforms/configurations:
> ??>> - Windows 2000/XP/2003 32-bit with MSVC 6, 7.0, 7.1 and future 8.0
> ??>> compiler - Windows 2000/XP/2003 32-bit with Intel ICC compiler -
> ??>> Windows 2003 64-bit with Windows 2003 SDK compiler - Windows 2003
> ??>> 64-bit with Intel ICC compiler
> ??>>
> ??>> What about VC 8 for x64 and IA64 platforms? Should they be
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.
Relying on third party tools is not an option at this stage.
> Although configuration script that I have written shall be easilty
> exensible for multiple compilers it is quite probable that some of these
> compilers may require additional changes.
That's great!
>
> MS> Even if we don't need to immediately accommodate any of these
platforms
> MS> now we should try to be as flexible as possible in order to make
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.
That's where the other script to generate the VS Solution will come
in handy :)
>
> MS> As an implementation note, I've seen two drop-down boxes in the IDE:
> MS> Configuration and Platform. It seems that Platform was designed to
> MS> be used to select a different hardware target (e.g., Win32 or Win64)
>
> That is right. In VS 8 there are 3 platforms - Win32, Win64 x64 and
> Win64 Itanium.
>
> MS> while Configuration to choose what we refer to as build type (e.g.,
> MS> Debug vs Release). If so, it would make sense to extend Platform to
> MS> include the compiler in addition to the hardware platform.
>
> 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.
There's no way to add a fourth Platform and beyond? There is a way
to add another compiler, isn't there? (I sure hope so, otherwise
we might have quite a bit more work to do than I thought). By
extending Platform I meant adding Intel C++/Win32, Intel C++/Win64,
and Intel C++/Win64 x64 to what's already there for MSVC. If there
is no way to do that, we might just have to generate a different
solution for Intel C++.
>
> ??>> Could you explain why MS projects files and GUI is needed?
>
> MS> I haven't used Windows as my primary development environment for
> MS> several years now but my assumption is that Windows programmers like
> MS> to work within the Visual Studio framework (I did when I was one)
> MS> and generally tend to avoid the command line (and on Windows they
> MS> do so for a good reason! ;-)
>
> I guess things are not so simple. It is convinient to develop your own
> projects in Visual Studio. But it is not so suitable for buiding 3rd
> party libraries (which is almost always one time operation), nightly
> builds, etc.
I used VS 5.0 to build libraries and executables that depended on
them and I don't recall any serious issues. I admit I never actually
tried to get automation working (or nightly builds), but I'm hopeful
that it won't be a showstopper. As long as dependcies among projects
work it should be possible to set up a system that will do what we
want (configure, build everything, and run it all to produce a
test report).
> Many teams prefer command line build for this purposes.
So do we. Unfortunately (or perhaps thankfully), the existing Rogue
Wave build infrastructure (RCB) is not part of stdcxx so we cannot
rely on it. The goal of this exercise is to get both the convenience
of the VS Solutions and Project as well as the flexibility of the
command line, ideally in one neat package.
[...]
> 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?).
My idea is that developers would generate the Solution with the
configuration script as one of its Projects. They would configure
(and reconfigure after changes to config tests) the library within
the Solution simply by right clicking on the Project and selecting
the Build menu option (at least I think that's how it's done).
>
[...]
> ??>> We should be able to invoke the MSVC projects from command line
or GUI
> ??>> and that will start the configuration script, run the tests and
> ??>> generate header, build libraries, locales, examples and tests (tests
> ??>> to come in future version).
> ??>>
> ??>> Probably it will mean that we will have to have different
projects for
> ??>> each MSVC version. It will be hard to maintain.
>
> MS> Maintenance cost is important. It would be good to minimize it as
> MS> much as possible. Writing a script to generate the projects and
> MS> solutions for the different versions might be one way of dealing
> MS> with the problem. The script input would be a set of compiler and
> MS> linker options along the lines of the various .config files (such
> MS> as gcc.config), the top of the stdcxx source tree (analogous to the
> MS> TOPDIR make variable), and the target version of Visual Studio. The
> MS> output would be a Visual Studio solution populated with a set of
> MS> projects, one for the library, and one for every other stdcxx
> MS> "component" such as each example, test, utility program, and locale,
> MS> complete with the required Configuration options (build types) and
> MS> Platform choices (compilers and hardware targets).
>
> 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.
But then we'd have to maintain the compiler options in two different
places: one in each Project within the Solution and the other in the
configuration script. The risk of the two diverging after some time
is just too great (we have quite a bit of experience with this
problem and its conseuqences are usually really nasty).
>
> MS> If we take this approach as I suspect we might need to, the script
> MS> will become *the* configuration and build infrastructure on Windows
> MS> and the generated solution and projects will be just one of its
> MS> (transient) products, just like the generated binaries. This approach
> MS> will then obviate the need to store the project solution and all of
> MS> its projects in SVN, or to distribute them to users.
>
> We could create the same solutions by hands from withing Visual Studio
> and then store them to SVN.
We could, but with all the problems I mentioned.
>
[...]
>
> MS> I think Andrew might have forwarded you his first tack at such
> MS> a script written in Perl. You might want to start with it as a
>
> No, I have not seen it. Regardless, I have not studied Perl, so it would
> not be very helpful.
The language doesn't matter. It's the concept that does. Let me
forward it to you privately so you can get an idea of how it
works and what the output is. I think Andrew implemented some
interesting things that might help you better understand what
I'm looking for.
>
> MS> reference and rewrite it in the scripting language appropriate
> MS> for the project. I haven't looked at his script yet, or at its
> MS> output, but some of the requirements on the final result is to
> MS> be able to invoke it from with options or arguments telling
> MS> Visual Studio to compile, link, and run the components of the
> MS> project and to to collect the output of each stage in a single
> MS> log file (for testing).
>
> Why not just to use ready solution to invoke build?
For all the reasons I mentioned above. I'm not completely ruling
this out but I would very, very much prefer not to have to deal
with the problems I'm concerned this approach would bring.
Martin
