My WebLink
|
Help
|
About
|
Sign Out
Home
Browse
Search
CRDSS_Task1_05-28_SoftwarePortabilityIssues
CWCB
>
Decision Support Systems
>
DayForward
>
CRDSS_Task1_05-28_SoftwarePortabilityIssues
Metadata
Thumbnails
Annotations
Entry Properties
Last modified
9/25/2011 10:18:52 AM
Creation date
5/30/2008 3:38:01 PM
Metadata
Fields
Template:
Decision Support Systems
Title
CRDSS Task 1.05-28 - Study of System Integration Issues Software - Portability Issues
Description
This memorandum discusses the issues related to software portability.
Decision Support - Doc Type
Task Memorandum
Date
5/10/1994
DSS Category
DMI Utilities
DSS
Colorado River
Basin
Colorado Mainstem
Contract/PO #
C153658, C153727, C153752
Grant Type
Non-Reimbursable
Bill Number
SB92-87, HB93-1273, SB94-029, HB95-1155, SB96-153, HB97-008
Prepared By
Riverside Technology inc.
There are no annotations on this page.
Document management portal powered by Laserfiche WebLink 9 © 1998-2015
Laserfiche.
All rights reserved.
/
5
PDF
Print
Pages to print
Enter page numbers and/or page ranges separated by commas. For example, 1,3,5-12.
After downloading, print the document using a PDF reader (e.g. Adobe Reader).
Show annotations
View images
View plain text
The subroutine would need to be different on each system. However, all other routines <br />GetTime <br />that call the routine time would remain the same from system to system. <br />GetTime <br />Different systems support different versions of common routines. For example, UNIX has two main <br />flavors: System V UNIX and Berkeley UNIX. Programs that are developed on one type of system <br />may not compile on the other type. Most of the differences in the systems are at a level that is <br />beyond the development scope of the CRDSS because CRDSS development efforts will mainly use <br />ANSI standard routines and not low-level system routines. <br />Different systems may also store files in different locations. For example, a library that is in one <br />directory on one system may be in a different directory on another system, or the library may have <br />different names on different systems. Differences between systems can be isolated into a compile- <br />imake make <br />time configuration file using the program (see Task Memorandum 1.05-21). If is being <br />uname <br />used alone, then a variable can be used to define the system type (use the UNIX program to <br />get the system type), which is then passed on as a definition to code if C or C++ is being used. <br />C preprocessor statements can be used to make code portable by allowing conditional tests at <br />compile time. For example, if different code is to be used for SGI's IRIX and IBM's AIX (IRIX and <br />AIX are the different vendors' implementations of UNIX), then the following code could be used: <br /># This is in the makefile... <br />program: .... <br />$(CC) $(CFLAGS) -DIRIX <br />/* <br />** This is in the C source code (probably in a header file)... <br />*/ <br />#ifdef IRIX <br />#define GetTime GetIRIXTime <br />#endif <br />#ifdef AIX <br />#define GetTime GetAIXTime <br />#endif <br />The variable definition in the makefile (-DIRIX) indicates that IRIX is the operating system. This <br />information is passed on to the C compiler, which in turn makes the definition to the C preprocessor, <br />which evaluates the statements and modifies the source code appropriately. <br />#ifdef ... #endif <br />The C code shown above will replace all occurrences of with , and would <br />GetTime GetIRIXTime <br />normally be placed in an include file so that it is transparent to developers. The code that is shown <br />does assume that the appropriate time routine is available on the system that is being compiled. If a <br />single version of a program is maintained for all platforms, then the and <br />GetIRIXTime <br /> routines would always exist (probably in a library). However, because the system- <br />GetAIXTime <br />dependent code in each routine may not be supported on a particular system, additional <br />#ifdef <br /> statements might be necessary to comment on inappropriate routine calls. Note that <br />... #endif <br />C preprocessor statements can usually be used with FORTRAN because many UNIX FORTRAN <br />compilers use the C preprocessor program; however, placing C preprocessor statements in <br />FORTRAN code is generally non-portable and can be confusing. <br />RTi proposes to use machines from different vendors to test the robustness of critical CRDSS code <br />and makefiles. For example, stand-alone MODSIM code will be compiled on an SGI workstation <br />2 <br />A275 05.10.94 1.05-28 Malers <br />
The URL can be used to link to this page
Your browser does not support the video tag.