Page History

...

For each package the SConscript file must be modified slightly to invoke the tool registerTargets rather than registerObjects. This has now been done for all packages in ScienceTools New, converted SConscript files have been committed and the packages are all tagged.   If you start with source from a recent ST LATEST build you don't have to worry about this.  Details of the differences are described below for the curious. Others should skip to the section GoGui Hints below.

Technical details

Wiki MarkupregisterTargets has a different interface. First of all, registerTargets makes finer distinctions between target types.    swig libraries are a category of their own, as are ROOT-using static libraries and ROOT-using shared libraries. For each category of library or executable target (e.g. static library, swig library, test app, etc.) instead of passing just a list of targets you pass in a list of pairs \[_[target_, _environment_\] where _environment_ is the environment used to create the target somewhere earlier in the SConscript file. Here is an example of the changes needed for the facilities package:

#Old form of register, using registerObjects
#progEnv.Tool('registerObjects', package = 'facilities',
#             libraries = [facilitiesLib, lib_pyFacilities],
#             testApps = [test_time, test_env, test_Util],
#             includes = listFiles(['facilities/*.h']))

#New, using registerTargets
progEnv.Tool('registerTargets', package = 'facilities',
             libraryCxts = [[facilitiesLib, libEnv]],
             swigLibraryCxts = [[lib_pyFacilities, swigEnv]],
             testAppCxts = [[test_time, progEnv], [test_env,progEnv],
                            [test_Util,progEnv]],
             includes = listFiles(['facilities/*.h']))

...

The problem is not VSlauncher, at least not exclusively VSlauncher. Hard-code the path to Studio 2008 devenv as the command to be issued has the same problem: devenv shows up as a running process in the Task Manager, but doesn't put up any windows until GoGui exits. However a command like the following works:

start "any title" path-to-VSlauncher path-to-sln-file

The title string is necessary even though it's not actually used for anything and is supposedly optional. path-to-VSlauncher has to be quoted since it typically includes spaces, so if there is no title start will think that path-to-VSlauncher is the title rather than the command.

...

• one known example of a ScienceTools package (evtbin) which compiles nicely under Studio 2003 but fails with Studio 2008. There may be more, another impediment to moving to Studio 2008.

• Wiki Markup-weirdness when building st_graph. After static library and test program (test_st_graph.exe) are built, SCons builds test_st_graph.lib. Who ordered that?- \ [June 9 update: turns out this has been happening for a long time with CMT builds as well as SCons. See e.g. RM output for v9r14 (static library) or v9r15 (dll).\]

June 2, 2009

After a lot of experimentation with building shared libraries rather than static for certain ST packages to avoid having to support static root libraries, I gave it up. There were too many mysteries. Instead I've added root static libraries to the list of supported project types.

...

Current stuff makes a per-package solution file with absolute paths for referenced project files, hence works no matter where the solution file is. Explicitly install it in directory pkg\visual-variant (e.g., facilities\Visual-vc90-Debug\facilities.sln).

...

• added line to create manifest files
• added to and rationalized compiler option lines
• added --vc9 option.

February 24, 2009

...

Have installed VS 2008 Professional. SCons finds it correctly when \ --vc9 option is used. Problems detected so far in the project and solution files that get written \ [and estimate of difficulty to fix\] include

1. Extra stuff at the end of the .vcproj file and the .sln file which appears to be for the private use of SCons, as SCons central expects these files to be used: that is, coerce Studio into calling SCons to do the actual build.  It may be harmless (or maybe not; it might have accounted for some of the strangeness I saw yesterday) but, for the kind of project files we're aiming for, it's certainly not useful. Eliminate it.  [easy]
2. Solution file version should be 10.0, not 9.0 [easy]
3. Warnings when I try to build the project about incompatible compile options [easy to medium]
4. No user include paths [medium or worse

5. Wiki Markup

   Extra stuff at the end of the .vcproj file and the .sln file which appears to be for the private use of SCons, as SCons central expects these files to be used: that is, coerce Studio into calling SCons to do the actual build.  It may be harmless (or maybe not; it might have accounted for some of the strangeness I saw yesterday) but, for the kind of project files we're aiming for, it's certainly not useful. Eliminate it.  \[easy\]

6. Wiki Markup
   Solution file version should be 10.0, not 9.0 \[easy\]

7. Wiki Markup
   Warnings when I try to build the project about incompatible compile options \[easy to medium\]

8. Wiki MarkupNo user include paths \[medium or worse\]

There are certainly many more; I just haven't gotten there yet.

...