To build GridLAB-D using MS Visual Studio 2005, do the following:
Download the source
Use an appropriate SubVersion tool (e.g., TortoiseSVN) or command to checkout a copy of the desired branch, ticket or the trunk. Be sure to keep each download in a separate source tree.
- Note
- If you intend to upload changes to the source tree you must login as a registered SourceForge user and be authorized to modify source by the GridLAB-D project manager.
Configure
Although this step is technically also done as part of the build process, executing it manually insures that external dependencies (such as MATLAB or MySQL) are properly included. To configure external linkages for the GridLAB-D build:
- Open a command window and change it to the /utilities folder (e.g., cd \GLDSource\trunk\utilities)
- Inside that folder, execute the command configure SOURCE=.. /f
- Once it succeeds, close the command prompt and continue to the next section.
Note that you only need to do this once, unless you install a new version of the external tools or change the install location.
Load gridlabd.sln
Start VS2005 and open the solution file workdir/VS2005/gridlabd.sln.
There are four valid targets:
- Debug win32
- Debugging version of 32bit gridlabd.exe
- Debug x64
- Debugging version of 64bit gridlabd.exe
- Release win32
- Release version of 32bit gridlabd.exe
- Release x64
- Release version of 64bit gridlabd.exe
Note that not all projects in a solution are supported in all targets. In addition various projects may be disabled in some source trees.
First time build
The very first time you build the file workdir/core/build.h is created. This file is not part of the source tree but is used by every other target and project. You must have enabled the command line option of subversion, which Visual Studio will use to create build.h.
Building an update
After an update to a source file (either from your coding or from a subversion update), you can build any of the valid targets.
One-time build projects
The following projects only need to be built once in each target and can be unloaded after the first build of that target to avoid unnecessary subsequent rebuild delays:
- CBLAS
- Provides the math library for SuperLU_MT
- Pthreads
- Provides the multithreading library for core
- SuperLU_MT
- Provides the math solver for powerflow
- Xerces
- Provides the XML library for core
Validation
It is vital that you run a validation test after building each target. We strongly recommend that you validate your build before starting any work. Then you can determine whether changes made by you or by others have affected the validity of your build.
The simplest way to validate GridLAB-D is
- Update the debugging properties for the core project
- Right-click on core in the Solution Explorer pane and click on Properties.
- Set Command to $(TargetPath).
- Set Command Arguments to -T n --validate, where n is the number of processors to use simultaneously. Do not try to use more threads than you have available processors. Using 1 will always work reliably and using 0 will automatically use all available processors. Regardless of the value of n you should get the same validation result. If you don't get the same result as n varies, that means something is wrong with the build.
- Set Working Directory to .. or to workdir.
- Click Ok.
- Set core as the active project
- Right-click on core in the Solution Explorer pane and click on Set as Startup Project.
- Press Ctrl-F5 to start the validation
- With a single thread, the validation process should take a couple of minutes. If n is greater than 1, the process should go n times faster. How fast it goes when n is 0 depends on how many processors are automatically assigned to the validation task.
- Review workdir/validate.txt
- Stable builds should have no validation errors. Release candidates and trunk builds may have a few validation errors although ideally there should be none. Ticket builds usually have many validation errors unless the ticket is pending validation.
Merging sources
You must merge changes from other related source trees and revalidate your build on all supported platforms before posting your changes to branch and trunk versions. Although regular merges from the original source tree is encouraged, changes to ticket versions can impede progress so the policy is much more flexible then. See Development/release_process page for details.
See also
- Development/release process
- Build platforms