Version 1 (modified by briadam, 7 years ago) (diff)

Initial developer getting started page

Developer Getting Started

See DeveloperSoftwareTools? for recommended utilities and versions for working as a DAKOTA developer.

See for DAKOTA design principles, source code documentation, style guidelines, and using DAKOTA as a library component.

Checking Out DAKOTA

The DAKOTA repository is separated into public and private meta-packages which use svn externals to pull components from public servers (anonymously) and from private servers (requiring authentication) to create a complete DAKOTA checkout. Due to a large number of externals, the checkout will take some time.

If you are an external developer, once Subversion is working, DAKOTA (including externals) can be checked out anonymously with the single command

svn checkout dakota 

If you are an internal developer and have appropriate permissions, DAKOTA can be checked out with the single command

svn checkout dakota 

Contact dakota-developers@… with authentication problems.

Svn will prompt you as to whether you wish to accept the SSL certificate from; consider selecting 'p' for permanent.

Subversion: Server Timeouts

Internal developers experiencing server timeouts might need to edit the $HOME/.subversion/servers file (generated for you the first time you run svn) by adding

http-proxy-exceptions = localhost, *
http-proxy-host =
http-proxy-port = 80

to the bottom of the file. If checking packages out from is slow, you might try adding your hostname to the http-proxy-exceptions line.

Subversion: Default Editor

To set the default editor for Subversion commits, you may add the following to .cshrc (or similar for .bashrc):

setenv EDITOR "xemacs -g 81X50"

Configuring and Compiling

See prerequisites at RequiredLibraries?

See platform-specific setup tips at PlatformSpecificSetup, including autotools examples.

For autotools builds of repository code you will need to autoreconf -i before proceeding with the usual configure/make. Developers typically though not always want options --enable-docs --enable-spec-maint

See CMakeFAQ for tips on configuring DAKOTA with CMake.


Once DAKOTA is built, then you can test it by going into the test directory in your build tree and running the test script:

cd test

This test script will take a while to run, typically an hour or more depending on your machine, producing dakota_diffs.out.

Commit Permissions

If you will be committing to the DAKOTA repository, work with your development team contact to

  • Acquire necessary accounts, passwords, and group membership
  • Be added to dakota-checkins and dakota-developers mailing list (mandatory for all developers)