Includes status, proposed strategies. Newest entries are at the top.
February 12, 2009
Can now build and run with 9.0. Link problem for debug was solved by specifying compile flag /MDd rather than /MD (thanks, Heather, for the hint). The inability to run was because manifest files created by the 9.0 linker were not getting installed. When I copied them to the proper place, all was well. Navid found mention of a variable WINDOWS_INSERT_MANIFEST in the SCons documentation which, when set to 'true', causes the manifest files to be installed automatically.
February 11, 2009
Was able to successfully build facilities non-debug, but couldn't run applications. Error message was "This application has failed to start because MSVCR90.dll was not found".
MSVCR90 (and a couple other libraries with similar names) are part of the Express 9.0 distribution. On my machine they can be found in directory
C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT
The debug versions are in a nearby Debug_NonRedist directory. I copied them all to C:\WINNT\system32, since that's where similar libraries for other Studio versions are, and rebuilt the applications, but that just changed the error to R6034: "An application has made an attempt to load the C runtime library incorrectly. Please contact the applicatins's support team for more information." ..not too helpful since I am the application's support team. And I still can't even link debug.
February 10, 2009
Windows server problems of yesterday were addressed. Using vs_revamp code from GoGui, can now
- build facilities package using Studio 7.1
- almost build facilities using Studio 9.0
Before I started on the vs_revamp gambit, I could not compile facilities with Studio 9.0 because the include path was missing a directory containing some system include files. That problem is fixed; all the sources in facilities compile successfully. The build now fails while trying to link the library:
Creating library facilities-02-18-02\build\XP-i386-32bit-Debug\facilities.lib and object facilities-02-18-02\build\XP-i386-32bit-Debug\facilities.exp Scheduler.obj : error LNK2019: unresolved external symbol __imp___CrtDbgReportW referenced..
February 9, 2009
Checked out the vs_revamp branch from the SCons code repository. Original plan was to use my existing 1.2.0 SCons installation and copy the new Windows stuff from vs_revamp into our site_tools/site_scons directory, but that failed in a mysterious way. Running vs_revamp in place according to instructions in a README file worked, but was not immediately compatible with invoking it from GoGui. Next I tried installing vs_revamp just as one would install the trunk (Subversion-speak for main branch) but couldn't get that to work either. By writing a little .bat file wrapper I am now able to run the vs_revamp version of SCons from GoGui; that is, I can get as far with it as I can by invoking it from the command line. That isn't very far at the moment because I can't reach the SLAC V disk, where the external libraries are. (There was a notice about problems with Windows servers today which, in theory, should not have touched any of the resources I need.)
Summary: After quite a bit of thrashing, net result is a small step forward.
February 2, 2009
The SCons developers are working on a better way to determine proper environment on Windows, depending on VS version. The idea is to find the appropriate set-up file (called something like vsvars32.bat), run it in a special subprocess starting with minimal environment and recover the output environment. This sounds like a much more robust and less-convoluted approach which we should certainly follow. I'm looking into how to get the relevant files, which exist only in a developement branch in their code repository.
January 30, 2009
With a newer version of VS installed on my machine, 7.1 (= VS 2003) is no longer the default. Had to make a couple small changes to SConstruct and to GoGui to recover the ability to build with 7.1 when that is not the default VS version.
Integrating Tracy's work into a local (in site_scons/site_tools) version of the msvs builder is easy; adding support for VS 9.0 turns out to be more difficult than expected. The SCons version of msvs and another related builder, msvc, includes a lot of code specific to various VS versions to find where Studio is installed, what belongs in include and lib path, etc. These things are different for each Studio version. Although VS 8.0 and 9.0 are similar in some ways, including project file format, the directory layout and registry layout are different. New code is needed to handle the 9.0 layout.
Heather made versions of swig, python and ROOT in directories labeled vc90, including at least those parts used by SCons to do builds. It's adequate for a mini-container with just the facilities package, enough to keep me going for quite a while.
January 8, 2009
Installed Express edition of VS 9.0. Since SCons as distributed does not specifically support it, plan is to
- add support for VS 9.0
- integrate work done by Tracy into the SCons msvs builder to improve project files part-way
- make more comprehensive improvements to msvs builder to get all files desired into project without hard-coding and to make multi-project solution files.
Mid-December 2008
SCons as distributed supports builds with Visual Studio 2003 (and should also with Studio 2005 but I haven't tried it), but generates project and solution files which are inadequate in several respects. Since format of project files changed substantially after VS 2003 and since Windows users would like to move forward, the decision has been made to work on project files, etc., only for VS 2008 (aka version 9.0).