Details of the capabilities of specific tools available on HECToR will be provided along with instructions on how to access them. We will not provide full details on how to use each of the tools as this is outside the scope of a good practice guide. We will however provide links to relevant sources of learning materials and further information.
The source code control system will enable multiple developers to work on the same code at the same time, managing associated problems, and ensuring that the integrity of the code is maintained by making it difficult for one developer to accidentally overwrite changes made by another developer. If two developers happen to make changes to the same file, the system may be able to automatically merge the two sets of changes.
Records are kept of which developer made which changes, so if necessary it is possible to find out who was responsible for any particular change. In addition, log messages are kept which can help you remember why changes were made.
Even if there is only one developer there are still advantages to using a source code management system; the system enables the developer to track changes over time, and recover older versions.
There are four source code control systems available on HECToR; CVS, SVN, Git and Bazaar. Any one of these may be suitable for your project and more details of each are given in the following sections. It is good practice to use source code control.
The server is responsible for combining your changes with the latest version, keeping track of version numbers and storing user supplied comments. If your working copy "conflicts" with the latest version some user intervention may be necessary to deal with the conflict before the server will accept the commit. To avoid these situations users are advised to regularly update their working copy against the latest version on the server.
We will not attempt to provide full details of how to use CVS here. Instead more information on CVS can be found in this CVS Manual. It covers setting up your repository, adding/deleting/renaming files and directories, branches, browsing the repository history, and much more.
The CVS commands are available on HECToR automatically without the need to load any modules.
If you do not already use a version control system and choose to start using a client-sever based version control system it is recommended you use SVN. For those currently using CVS and wishing to switch to SVN there is a tool available, cvs2svn.
A very good and full guide to using SVN for your project can be found in this SVN Book. To make the SVN commands available on HECToR you will need to load the SVN module.
Changes are copied from one developer's local repository to another developer's as an additional development branch. This additional development branch can then be merged with any locally developed branches to get an updated version of the code.
As Git uses the distributed model there is much branching and merging and Git does this very efficiently. Git is also very fast for fetching revision histories due to the information being held locally. It performs especially well for large projects as Git does not get much slower as the project history grows.
There are numerous Git tutorials, from quick start guides to the full manual, available on the Git Tutorials.
To make the Git commands available on HECToR you will need to load the Git module.
For more details on Bazaar and how to use it please see the Bazaar documentation.
To make the Bazaar commands available on HECToR you will need to load the Bazaar (bzr) module.
There will be numerous dependencies between the files meaning they need to compiled and linked in a particular order. You may also want to have a series of different builds which require a different set of compiler options (debugging or release builds) or linking against different libraries. As the complexity starts to grow issuing all the commands on the command line becomes tedious and is prone to error. Implementing a build system using one of the build tools detailed here will manage many of these complexities by automating much of the build process.
Other advantages include:
A Makefile consists of a set of rules, targets and dependencies. "Rules" tell make what commands to issue to create a specific "target". It also lists the "dependencies" of each "target", which are those files which the commands issued in the "rule" require.
When you type "make" on the command line Make will attempt to build the first target in the Makefile. You can also specify which target for Make to build by specifying the target on the command line. Make will follow the rules specified in the Makefile to build the desired target. It will also issue any rules to build other targets which are listed as dependencies for the target you've asked it to build.
Makefiles can be as simple or as complex as you like. For full details see the GNU Make Manual. The manual gives full details of the Make system as well as a series of example Makefiles which can be adapted for your project.
Automake produces portable Makefiles for use with GNU Make, described above. The developer specifies their build needs in a Makefile.am file. Automake then transforms this into a Makefile.in file which is taken by the configure script (generated with Autoconf) to produce the final Makefile for the user's system.
Autoconf is the tool for producing a "configure" script for your project. A configure script will be run prior to the installation of your software. It inspects the user's system and then generates appropriate Makefiles and header files for the system. The configure script is there to make life easier for users of your software. Autoconf does not automatically generate a configure script but instead relies on the developer specifying how the configure script should behave in a configure.ac file. Autoconf can then take the configure.ac file and turn it into a portable configure script.
Libtool is used to create portable libraries, either static or dynamic. Creating portable libraries can be difficult as systems often have different shared library formats, different flags to create libraries or may not support shared libraries at all. Keeping track of this in a Makefile is a very complex task. Libtool attempts to provide a solution to this problem. Libtool does this by providing a new library format (.la) which abstracts all others. Libtool provides a wrapper around the compiler and linker to specify the correct system specific flags so that in your Makefile.am you create and link against .la files. In this way all system specific details are dealt with by Libtools.
For a full explanation on using these tools see the Autotools Tutorial.
Numerous quality tutorials, manuals and guides can found on the CMake Documentation page.
The full suite of CMake tools are available on HECToR by loading the CMake module.