ROOT is currently archived in CMZ which is cvs and gmake and a scripting
language and a bit of the VC++ ide all rolled into one. As currently
configured, the build process is quite easy when you get it correct.
However, the experience is much like working with SoftRelTools: it is very
fragile. Drop a "WinNT" one place, or start from the wrong directory another
place and you won't get a warning, rather you get a totally failed build.

I would like to thank Valeri Faine, from BNL, for helping out. He is a
former member of the ROOT team and coded most of the Windows NT support for
ROOT. He helped me through most of my initial setup problems.

I have Visual C++ 6.0 installed on my machine. It is my understanding that
ROOT has not been ported to the 6.0 version of the MSVC compiler yet. Indeed
there were several build errors that prevented a clean compile the first
time through (for example, "function with C linkage cannot return an C++
object"). The compile time errors were pretty easy to fix (by getting rid of
the extern "C").

There were a number of cast-ing errors in the win32 library as well as the
gui library. Also in the gpad there were string-too-long errors (there may
be a compiler option around this, I'm not sure).  There was something wrong
with the inheritance hierarchy in TRootIconBox -- it couldn't get at its
SendMessage method in the Refresh method and in cmz it is very hard to trace
object hierarchies. Also got several undefined symbols during the
construction of sharable libraries. For example, in CINT
_real@8@00000000000000000000.

The result was I was unable to build root in an evening. Bringing it up to
snuff for VC6.0 should take only about 2 or 3 days or work. Shorter if the
person is familiar with root's object hierarchy.

There are two options for maintaining the build on NT when cmz is left
behind. If gmake is used then the make files must be designed with
sufficient generality (i.e. better than the SRT makefiles) so that it is
very easy to switch from platform to platform. The only place this presents
a problem is filepaths, however if relative paths are stuck to and symbolic
links are not employed, this should work just fine.

The second option is to maintain a set of IDE files: a workspace and project
for each target (library, shared library, or executable). Valeri attempted
to do this but had to give up because of the rapidity (and unnotified)
changes that occurred with the base build scripts in cmz. The up-shot was he
found it very difficult to track the cmz scripts with his IDE files.
However, since real development will be required on NT to maintain the
graphics and windows classes I suspect this option is worth investigating
further.

I do not expect either of these two conversion methods to take very much
time. As long as the cmz to UNIX conversion perhaps. Maintaining the system
I expect to be fairly difficult judging by our experience with SoftRelTools
and the way the ROOT team is used to developing. If code development of ROOT
is to remain free-wheeling and fast, and with lots of the initial
development happening on the UNIX platform, then it is advisable use a
general makefile to build on NT. In fact, a very general makefile will have
to be constructed so that root can build on all of the UNIX platforms
currently supported.  In this case the NT developer will have to develop
some independent system for building the NT files in an IDE (it is unlikely
my translation scripts will work with out major modifications outside the
SRT environment).