Discussion concerning SCons and Visual Studio

29 May 2007 19:00:59.0654

Apparently the SCons people have done a fair bit of work to make "proper" project/solution files that are compatible with several versions of visual studio. They just dropped the ball on making project files that will allow you to actually build those projects from within visual studio.
It seems to me to be straightforward to take the work you have done and plug it into the "correct" places in the existing SCons stuff to make project files. I'm not claiming to be a python/scons expert but from what I read this sure looks like a simple path which could be made somewhat separate from the question (which I still am not sure was resolved) of whether one keeps or gets rid of requirements files.
With respect to the shareables question, my point was that the SCons command to build a shareable on windows does not, for some reason, appear to fully work. It looks to me that SCons separates the building of packages from the creation and use of project/solution files, in particular not using the project/solution files in the actual building of libraries, executables, whatever. So, I'm guessing we would need to look at this more carefully anyway since I'm assuming that MRstudio/MRvcmt would be happier just issuing a "standard" SCons build.
Tracy

Toby Burnett wrote:A few comments:
About making shareable dlls without needing the special code "dllspec"stuff: I solved that. It works fine. It works fine. The other thing that I wonder if SCons does is to make a solution filethat has all the projects that the given one depends on, with properdependence. And with a switch to decide if one wants to check them forrebuilding. I solved that, too. But my solution depends on having thedependency tree, as currently provided by CMT. Surely my code could beinvoked by the SCons builder, but can it pass this information?
--Toby

29 May 2007 17:08:27.0573

I am not ready to say "breakthrough" but really rather more of an understanding. I am no python expert so I'd say I can sort of read it but am not ready to program anything... Anyway, I have been going through the SCons ms files (msvs.py, msvc,py, mslink.py and mslib.py) and then comparing that to "hello world" type project and solution files and also comparing to Toby's pycmt files.

Basically, in msvs.py, SCons inserts a "VCNMakeTool" where it then calls its own stuff to build projects, external to Visual Studio. I find this unsatisfying, within Visual Studio none of the c++ files can be built, the libraries can't be built, you can't change options, etc., etc. On the plus side, SCons will build debuggable code but you definitely give up some of the nice features (primarily because it appears to do a minimal debug build... perhaps sufficient for standard glast usage but not what I personally prefer).

What I think we should do is to follow the pieces that Toby has where we insert the "standard" compile, pre-link and link tools into the project files so that Visual Studio has the ability to build and link the code. And, along the lines of what SCons is doing, we could also make this backward compatible with the current version of Visual Studio.

Now, if I understand how SCons works, then this would really be for developers convenience since if you ask SCons to build a project it will do it independently of the Visual Studio project and solution files that it creates. Or at least that seems to be the case with my simple little HelloWorld application (which is one step more complicated as I have it set up to build a main which links to an object library with the "helloworld" output). However, if we follow the path that Jim provided with a default SConstruct file setting up all the "standard" parameters then I think we could assure that the SCons build and the Visual Studio built would be the same.

As an aside... I have not been able to figure out how to build a shareable library that I can link to. I'm sure this can be done, but not with the advertised SCons command since it produces only the .dll file and does not produce, even though it says it will, the corresponding .lib file used by the linker. Past this, I'm also not exactly sure yet how we teach SCons about the, basically, two types of libraries we have (Gaudi shareables with only, on windows, the Gaudi components accessible externally) and "linker libraries" where we use either cmt or root tools to expose all the symbols.

Another aside... I was not completely sure of the direction we were heading in... in particular, if going in the SCons direction, whether we were abandoning cmt requirements files or not.

Anyway, since I am not a python programmer and since the SCons ms files are rather large and complicated, and because I don't completely understand some of the SCons details yet, there are definitely some Visual Studio things to understand, etc., this is not yet going at a lightning pace...

Tracy

  • No labels