Port existing project - Revision history

Brad Berg at 13:49, 22 April 2010

2010-04-22T13:49:52Z

← Older revision		Revision as of 13:49, 22 April 2010
Line 9:		Line 9:
	* 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.		* 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.		* To foster collaboration 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 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.

Brad Berg at 13:48, 22 April 2010

2010-04-22T13:48:11Z

← Older revision		Revision as of 13:48, 22 April 2010
Line 1:		Line 1:
	~~Before porting your project,~~ you ~~may wish to take a look at documentation on the [[Transition to new $G\|transition to the new $G]]~~.		Migrating existing projects with their source control histories intact involves CVS operations that can only be done by an administrator. Please see Brad if you need help with this process.

	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.		Here are a few things to check for when migrating existing code.

	~~There~~ are a few things to check for when migrating existing code.

	* Organize the directories according to how you want them stored in CVS.		* Organize the directories according to how you want them stored in CVS.

Brad Berg at 13:45, 22 April 2010

2010-04-22T13:45:37Z

← Older revision		Revision as of 13:45, 22 April 2010
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.

Brad Berg at 13:44, 22 April 2010

2010-04-22T13:44:44Z

← Older revision		Revision as of 13:44, 22 April 2010
Line 13:		Line 13:
	* 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.		* 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 and in the long run saves everybody time.		* 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'''.		* 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'''.

Brad Berg at 13:43, 22 April 2010

2010-04-22T13:43:21Z

← Older revision		Revision as of 13:43, 22 April 2010
Line 9:		Line 9:
	* Often existing projects use '''.C''' and '''.H''' suffixes. Where reasonable convert them to '''.cpp''' and '''.h'''.		* 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.		* 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.		* 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.

Brad Berg at 13:42, 22 April 2010

2010-04-22T13:42:00Z

← Older revision		Revision as of 13:42, 22 April 2010
Line 15:		Line 15:
	* 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 and in the long run saves everybody time.		* 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 and in the long run saves everybody time.

	* If the package uses libraries that are not already ~~supported~~ you will need to set them up.		* 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 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.

Brad Berg at 16:05, 21 April 2010

2010-04-21T16:05:03Z

← Older revision		Revision as of 16:05, 21 April 2010
Line 3:		Line 3:
	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.		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 ~~general steps~~ for migrating existing code.		There are a few things to check for when migrating existing code.

	* Organize the directories according to how you want them stored in CVS.		* Organize the directories according to how you want them stored in CVS.

Brad Berg at 16:04, 21 April 2010

2010-04-21T16:04:07Z

← Older revision		Revision as of 16:04, 21 April 2010
Line 1:		Line 1:
	Before porting your project, you may wish to take a look at documentation on the [[Transition to new $G\|transition to the new $G]].		Before porting your project, you may wish to take a look at documentation on the [[Transition to new $G\|transition to the new $G]].

	At this point, porting existing projects along with their source control histories ~~is a tricky undertaking~~. Please see Brad ~~for~~ help with this process.		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 general steps for 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.

			* 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 and in the long run saves everybody time.

			* If the package uses libraries that are not already supported you will need to set them up.

Trevor O'Brien: New page: 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 the...

2010-04-19T15:48:50Z

New page: 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 the...

New page

Before porting your project, you may wish to take a look at documentation on the [[Transition to new $G|transition to the new $G]].

At this point, porting existing projects along with their source control histories is a tricky undertaking. Please see Brad for help with this process.