== How to become a CIVL developer ==
* If you are interested in contributing to the development of CIVL, send an email to civl-users@googlegroups.com expressing your interest, and we'll get back to you.   We can use help in many areas, including testing and creating new examples, and we are very open to new ideas on all aspects of the project.
* The lead developer will perform the following tasks:
 * Add you to the civl-dev@googlegroups.com email list.  You will be able to read and post messages to this group.   Use it to discuss any development issues.
 * Create a Subversion account for you in the appropriate projects (CIVL, ABC, SARL, GMC).  You will then be able to commit to the `branches` directories in those repositories.  (All of the repositories are already world-readable.)
 * Create a Trac account for you.  You will then be able to create and modify bug/issue tickets, and write to the Wiki.  (The tickets and Wiki are already world-readable.)

== How to make changes or additions to CIVL ==
1. To make any changes or additions to CIVL, you must first become a CIVL developer.   See above.
1. Before embarking on any major changes or additions, talk to the other developers.  This is best done using the email list civl-dev@googlegroups.com.  Explain what you want to do, and listen to the feedback.
1. Create a new branch for the new features you want to add into CIVL.  Name your branch anything you like and create it in the branches directory of the repository.  See "Using Subversion from the command line" for instructions on creating the branch.
1. There are two different ways to work on your branch in Eclipse.   The first way is appropriate for relatively small changes that do not involve a lot of components.   In this approach you check out your branch into the current workspace, giving the project a different name from existing projects, e.g., `CIVL_mybranch`.   In the second approach, you create a whole new workspace with all four projects.  In this approach you can stick with the standard names for all projects (`CIVL`, `GMC`, `SARL`, `ABC`).   This approach is appropriate when you have bigger changes affecting multiple components.
1. Proceed with development of your branch, committing as often as you like.  Periodically, merge changes from the trunk into your branch, and resolve any conflicts that result.  This will make it much easier to integrate your branch into the trunk later on.  Be sure to follow the CIVL  [wiki:"Coding Standards"] and the [wiki:"Coding Standards for CIVL models"].
1. Create unit tests and system tests for your new code, making sure they provide 100% statement coverage of your code, at a minimum.  You may also need to make changes to existing tests.
1. Have at least one other CIVL developer review your code.   Your reviewer will make suggestions for improvements.  Iterate until both of you are satisfied.
1. When you feel your branch is complete, send an email to civl-dev@googlegroups.com.  In the email, give the name of your branch and summarize the changes/additions you have made.   We will then schedule a CIVL meeting where your contribution will be discussed.    All developers will be given some time to review your branch before the meeting.
1. At the meeting, your branch will either be accepted or it will be rejected with suggestions for further changes.  If accepted, it will be merged into the trunk.  Only the lead developers have permission to do this merge.    If further changes are suggested, a future meeting will be scheduled to discuss again.


 We recommend using the Eclipse IDE to write CIVL code.  Remember to set your Java code formatter as "built-in 2.1" in your Eclipse.

== How to set up CIVL in Eclipse ==
1. Install  theorem provers [http://www.cs.nyu.edu/acsys/cvc3/ cvc3], [https://github.com/CVC4/CVC4 cvc4] and [https://github.com/Z3Prover/z3/releases z3] following the instructions provided with those tools.  CIVL uses only the command line interface for these tools, so you don't have to worry about installing libraries or anything other than the executable binary.   Make sure the executable is somewhere in your PATH.
1. Install Eclipse IDE for Java/EE developers if you have not already done so.
1. Install an SVN plugin in Eclipse (such as Subversive) if you have not already done so.
  a. Use [https://marketplace.eclipse.org/content/subversive-svn-team-provider Subversive Installation instruction] to install all components (except for the connector, which may not be included in this package).
  a. Open Eclipse: 'Help>>Install New Software..>>Add..' and enter '''!http://community.polarion.com/projects/subversive/download/eclipse/6.0/update-site''' as the value of 'location' with preferred name tag in 'name'.
  a. Expand '''Subversive SVN Connectors''', then selected both ''Subversive SVN Connectors'' and ''SVNKit''
  a. Install these two components by clicking ''next'' and following instructions shown.
1. If you already have the VSL dependencies library, you may skip this step. Otherwise, download the tgz archive of VSL dependencies from [http://vsl.cis.udel.edu/lib/tools/vsl_depend  http://vsl.cis.udel.edu/lib/tools/vsl_depend]. Unzip the .tgz file and you will have the folder named `vsl`. Move `vsl` directly under  `/opt` (this might require `sudo`).  
1. Install prerequisite projects ABC, SARL and GMC. Make sure that the three projects are put in the workspace directory where CIVL will be created.  Specifically:\\ \\
   * Install the symbolic algebra and reasoning library SARL. In Eclipse, select New Project...from SVN, and use the archive  svn://vsl.cis.udel.edu/sarl. After entering that, open it up and select the "trunk" (or the appropriate branch if you are working on a branch). The project by default will be named "SARL" and there is no reason to change this unless you want to have two different branches of SARL existing simultaneously in the same workspace. Then follow the instructions in SARL's INSTALL file for Eclipse installation.  As those instructions explain, if the default settings in `build_default.properties` are not appropriate for you, then create a copy called `build.properties` in the same directory and edit it as you will.  (This copy will be ignored by version control.)  Build `sarl.jar` from within Eclipse by right-clicking (or ctrl-clicking) on the `build.xml` file and selecting Run As->Ant Build. \\
 \\
   * Install the C front-end ABC. In Eclipse, select New Project...from SVN, use the archive svn://vsl.cis.udel.edu/abc.   The process is exactly like the one for SARL described above. \\ \\
   * Install the generic model checking utilities package GMC. In Eclipse, select New Project...from SVN, use the archive svn://vsl.cis.udel.edu/gmc.  Same process. \\ \\
1. From within Eclipse, select New Project...from SVN. The archive is svn://vsl.cis.udel.edu/civl.   Follow the same process as with the other 3 projects to install CIVL.
1. Navigate to Preferences -> Java -> Build Path -> !ClassPath Variables, and then select New to create a classpath variable `VSL`, and specify its value to be `/opt/vsl`.
1. Do a clean build.  Everything should compile.  Generate `civl.jar` by right-clicking (or ctrl-click on OS X) the `build.xml` file and Run As->Ant Build.
1. Somewhere on your system, create a plain text file containing exactly the following two lines: 
  {{{
#!/bin/sh
java -jar /Path/To/Your/workspace/CIVL/civl.jar $@ 
  }}}
  where {{{/Path/To/Your/workspace}}} is replaced with the path to your Eclipse workspace directory.  Name this file `civl`, put it in your `PATH`, and make it executable (`chmod ugo+x civl`). Alternatively, you can define an alias in your `.profile`, `.bash_profile`, `.bashrc`, or equivalent: 
{{{
alias civl='java -jar /Path/To/Your/workspace/CIVL/civl.jar'
}}}
1. From the shell (terminal window), execute `civl config`.  This should find the theorem provers in your `PATH` and create a file `.sarl` in your home directory.
1. In Eclipse, navigate to "Run->Run Configurations... Create a new JUnit configuration."   Name it "CIVL Regression Tests". Select "Run all tests in the selected project..." and navigate to the folder `test/regress` in the CIVL project. The Test runner should be JUnit 4. Under the Arguments tab, type `-ea` in the VM arguments area (to enable assertion checking).
1. An example of how to set up a single test from within Eclipse: \\ create a new Run Configuration via the Run->Run Configurations... menu.  Create a new "Java Application" configuration.  Call it `CIVLbarrier2`.  The Project is CIVL. The main class is `edu.udel.cis.vsl.civl.CIVL`.  Under the Arguments tab, set the Program arguments to `verify examples/concurrency/barrier2.cvl`.  Modify the VM arguments as in the step above.  You should now be able to run the test by clicking "Run".

== Using Subversion from the command-line ==

* CIVL uses Subversion to manage source code. The CIVL Subversion repository is structured in the typical way.  In particular, the repository contains directories named `trunk`, `branches` and `tags`.
* To create a new branch named `branch_name` from the current trunk, type
{{{
svn copy svn://vsl.cis.udel.edu/civl/trunk svn://vsl.cis.udel.edu/civl/branches/branch_name
}}}
* Once a new branch has been created, you can check out your new branch with the command
{{{
svn co svn://vsl.cis.udel.edu/civl/branches/branch_name
}}}
You can also create a new Eclipse project from that branch, in the usual way.
* Within your own branch, you can change anything you want to implement your changes or additions, and you can commit your changes to the svn server so that you won't lose your work.
* To merge changes made to the trunk into your branch, change into your local branch directory and type
{{{
svn merge ^/trunk  .
}}}
Resolve any conflicts and when you are satisfied with the state of your local copy, commit it as usual.
Do this regularly (or whenever changes are committed to the trunk) in order to reduce the work of resolving conflicts when you decide to merge your branch back to the trunk.
* To see a summary of the merge history from the trunk to your branch, go into your branch directory and type 
{{{
svn mergeinfo ^/trunk
}}}
* Lead developers only: to merge a branch back to the trunk, change into your local copy of the trunk directory and type
{{{
svn merge ^/branches/branch_name .
}}}
Resolve conflicts as needed and make sure all tests pass.  Then commit the trunk.  At this point the branch may be deleted (`svn remove ^/branches/branch_name`) or it can be kept around if the developer wants to continue to use it.