Port existing project: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 19: | Line 19: | ||
* Create a '''READ_ME.txt''' file in the top level directory to document any special build or usage instructions. Also provide any end user documentation. | * Create a '''READ_ME.txt''' file in the top level directory to document any special build or usage instructions. Also provide any end user documentation. | ||
* Check online to see if the vendor has a newer version available. Install and work with the latest version. If the package uses libraries that are not already installed you will need to set them up. | * Check online for third party software to see if the vendor has a newer version available. Install and work with the latest version. If the package uses libraries that are not already installed you will need to set them up. | ||
Revision as of 13:45, 22 April 2010
Before porting your project, you may wish to take a look at documentation on the transition to the new $G.
At this point, porting existing projects along with their source control histories involves CVS operations that can only be done by an administrator. Please see Brad if you need help with this process.
There are a few things to check for when migrating existing code.
- Organize the directories according to how you want them stored in CVS.
- Often existing projects use .C and .H suffixes. Where reasonable convert them to .cpp and .h.
- Some existing projects duplicate code already in CVS. If there is any duplicate code eliminate it and revise your code to use the common code. This might involve promoting common code to a library in the common/ directory.
- We would like to develop architecture neutral software. Where reasonable rewrite code that is not portable. Your code should not rely on Unix utilities or use links. We are standardizing on Python as a scripting language as it is easy to write portable scripts with it. You're not expected to completely port software; just avoid making that hard to do should someone want to in the future.
- Eliminate compiler warnings where possible. The build system lets you compile your code with several compilers; each of which will issue different warnings. Try out as many as you can. This process will often find bugs in the short term and in the long run saves everybody time.
- Eliminate or document conditional compilation. In C/C++ these are typically #ifdef statements. Ideally conditional compilation should be removed from source code files and promoted to the top level Makefile in a project. If that is difficult to do then try to limit #ifdef statements to a single occurance in a header file. Document conditional compilation in the top level Makefile.
- Create a READ_ME.txt file in the top level directory to document any special build or usage instructions. Also provide any end user documentation.
- Check online for third party software to see if the vendor has a newer version available. Install and work with the latest version. If the package uses libraries that are not already installed you will need to set them up.