From GridLAB-D Wiki
Jump to: navigation, search

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