GoGui seems to be a bit sensitive... my downloaded version of GlastRelease was crashing GoGui when I would type "to_install" in the command line entry box. This went away when I did a full clean and then started over with setup, to_install and then StudioFiles.
First success with the new GlastRelease: have built facilities and run the test programs. However, to run the test programs I had to "start debugging" and then let VS rebuild all the packages before it could seem to find the program to run.
So far attempting to build and run the G4Generator test program is not quite working for me... If I start by right clicking on G4Generator and opening Visual Studio then all seems to be right, and it goes through the build procedure for G4Generator with no issues (lots of warnings about not finding the pdb files for CLHEP but I can live with that for now). When I try to build the test_G4Generator application in Visual Studio it fails because it can't find the two cxx files it needs: testGlastMain.cxx and setPriority.cxx, both of which are located in the gr_app package. It looks like Visual Studio is looking in the xx/GlastRelease_Latest/studio/Windows-i386-32bit-vc90-Debug folder for both.
However, if I build G4Generator from GoGui then, indeed, it is able to build test_G4Generator so it seems to have the correct path sorted out there.
Unfortunately, when I open Visual Studio AFTER building test_G4Generator in GoGui, I still can't run the test program. When I click run it immediately comes back telling me all the libraries and the application are out of date and need to be built AND if I let it do that it again fails building the test application since it can't find the two source files it needs.
Studio *always* seems to think everything is out of date, even in cases where it is able to build everything itself. It builds, then when you try to run something it will complain yet again that everything is out of date. I would like to track this down, but meanwhile I have just been ignoring the warnings when I have reason to believe everything really is up to date.
Question: I am in Visual Studio debugging a program and see an error in a header file. I stop debugging, modify the header file and then try to rebuild the affected package. But which copy of the file have I modified and will the modification propagate back to the right place?
I don't know which copy you've modified. The one you ought to modify is the one in the original source tree. The build process with SCons will copy from there to the working build directory and I think the VS build also does (but uses a different working directory). Too bad VS 2008 doesn't support sym links.
However, the project files as currently constituted do not do an install of headers (or xml files, job options, etc.) as is done by SCons. I'm working on this. Probable technique will be to add a post-build event step to all project files which build libraries. The post-build step will invoke a .bat file (written by SCons at the same time as the project and solution files) which copies all files which need to be installed. A drawback (which I think is inevitable and not unique to this install step) is that, if any files are added or subtracted from the package, you'll have to do a rebuild of the project and solution files - and the new .bat file - from SCons.
Update: Implementation is finished. To use it, update SConsFiles package. The new code is in tag SConsFiles-00-21-00
5 Comments
Tracy Usher
GoGui seems to be a bit sensitive... my downloaded version of GlastRelease was crashing GoGui when I would type "to_install" in the command line entry box. This went away when I did a full clean and then started over with setup, to_install and then StudioFiles.
First success with the new GlastRelease: have built facilities and run the test programs. However, to run the test programs I had to "start debugging" and then let VS rebuild all the packages before it could seem to find the program to run.
Tracy Usher
So far attempting to build and run the G4Generator test program is not quite working for me... If I start by right clicking on G4Generator and opening Visual Studio then all seems to be right, and it goes through the build procedure for G4Generator with no issues (lots of warnings about not finding the pdb files for CLHEP but I can live with that for now). When I try to build the test_G4Generator application in Visual Studio it fails because it can't find the two cxx files it needs: testGlastMain.cxx and setPriority.cxx, both of which are located in the gr_app package. It looks like Visual Studio is looking in the xx/GlastRelease_Latest/studio/Windows-i386-32bit-vc90-Debug folder for both.
However, if I build G4Generator from GoGui then, indeed, it is able to build test_G4Generator so it seems to have the correct path sorted out there.
Unfortunately, when I open Visual Studio AFTER building test_G4Generator in GoGui, I still can't run the test program. When I click run it immediately comes back telling me all the libraries and the application are out of date and need to be built AND if I let it do that it again fails building the test application since it can't find the two source files it needs.
So... will give up on this for the evening.
Joanne Bogart
Studio *always* seems to think everything is out of date, even in cases where it is able to build everything itself. It builds, then when you try to run something it will complain yet again that everything is out of date. I would like to track this down, but meanwhile I have just been ignoring the warnings when I have reason to believe everything really is up to date.
Tracy Usher
Question: I am in Visual Studio debugging a program and see an error in a header file. I stop debugging, modify the header file and then try to rebuild the affected package. But which copy of the file have I modified and will the modification propagate back to the right place?
Joanne Bogart
I don't know which copy you've modified. The one you ought to modify is the one in the original source tree. The build process with SCons will copy from there to the working build directory and I think the VS build also does (but uses a different working directory). Too bad VS 2008 doesn't support sym links.
However, the project files as currently constituted do not do an install of headers (or xml files, job options, etc.) as is done by SCons. I'm working on this. Probable technique will be to add a post-build event step to all project files which build libraries. The post-build step will invoke a .bat file (written by SCons at the same time as the project and solution files) which copies all files which need to be installed. A drawback (which I think is inevitable and not unique to this install step) is that, if any files are added or subtracted from the package, you'll have to do a rebuild of the project and solution files - and the new .bat file - from SCons.
Update: Implementation is finished. To use it, update SConsFiles package. The new code is in tag SConsFiles-00-21-00