VizSchema

# HowToDevelop

# How to Develop the Vs Plugin 

The source code for the Vizschema plugin resides in several repositories. One is local to Tech-X, and is the recommended location for all branching, development, and testing. The other is part of the official VisIt repo, and holds the code that will actually be released with VisIt binary releases. Naturally, the VisIt repo is not the recommended location for development commits. However, it should be kept essentially up-to-date with the "trunk" version of the local repo. 

**Checking out and building VisIt with Bilder**

To test the Vs plugin you will need a working [VisIt](https://wci.llnl.gov/codes/visit). Although it is not necessary in many cases to build VisIt, as installers and binary versions can be downloaded from the VisIt web site, a custom built VisIt will allow you to make modifications that go beyond the VizSchema plugin. 

We recommend building VisIt with Bilder, a meta-build system, which stores inter-dependency information between packages. A bilderized version of the VisIt project is hosted on sourceforge. Bilder runs on Linux, Mac OS X, and Windows among other platforms. Be sure to prepare your platform according to the [instructions](https://ice.txcorp.com/projects/bilder/wiki) prior to building VisIt. 

To check out VisIt type 

```

svn co https://svn.code.sf.net/p/bilder/code/visitall/trunk/ visitall

cd visitall

```

So that this build does not interfere, we recommend to build in a separate space:

```

cd visitall

./mkvisitall-default.sh -r /sfbilder -c

```

**Checking out and building vsreader**

The VizSchema repo is available here: 

```

https://ice.txcorp.com/svnrepos/code/vizschema

```

It is highly recommended that one makes a branch before doing any development. This allows the developer to commit code and then test it on various different platforms before making the changes publicly available. 

**Configuring**

The stand-alone VizSchema repo contains CMake build files to allow building against an INSTALLED version of VisIt. If the developer needs to build against a DEVELOPMENT copy of VisIt, the only good solution is to copy the Vs source files into the VisIt source directory (src/databases/Vs) and then build using the VisIt system. 

On a system that has been built with "bilder", using the default install directories, the CMake script should not require any additional arguments: 

```

cmake .

```

You also can build out of space: {{{cd vizschema/trunk mkdir build cd build cmake .. }}} On many systems, the developer will need to provide the path to the VisIt install: 

```

cmake  -DSUPRA_SEARCH_PATH:PATH='/sfbilder/volatile;/sfbilder/contrib' \

   -DVisIt_ROOT_DIR=/sfbilder/volatile/visit_trunk \

   ..

```

This location will work on iter where VisIt's trunk is installed as shown above. 

**Building**

On Mac and Linux, run

```

make

```

On Windows/cygwin, run 

```

nmake

```

or

```

jom

```

This will install the plugin under $HOME/.visit/<version>/<os>/plugins/databases/. 

*Installing*

No special install step is needed. At runtime, VisIt will load any plugins from the $HOME/.visit/<version>/<os>/plugins/databases/ directory. If a plugin in .visit conflicts with a plugin that is installed with VisIt, it will use the one from ~/.visit (i.e. your development version). On my (Marc Durant) machine the plugins are install in ~/.visit/2.4.0/darwin-x86_64/plugins/databases 

*Debugging*

In order to debug the plugin, run 

```

visit -debug 5 &

```

with the -debug 5 option. This will generate debugging logs for every piece of the visualization process. Generally speaking, metadata errors will show up in the mdserver vlog files, and data errors will show up in the engine vlog files. The Vs plugin uses two different levels of VisIt debugging log to output messages. Errors will appear in level 3 (and higher), while debugging messages will only appear in level 5. 

**Coding Standards**

The VisIt team is very strict about certain aspects of code formatting. As an independent plugin, Vs has a bit of latitude, but we attempt to follow the VisIt formatting conventions where possible.

*NO TABS - all source code must be 2-space indented, with absolutely no tab characters

*Doxygen - we are slowly bringing all source files up to a full level of Doxygen documentation