Geoscience Reference
In-Depth Information
influenced by the availability of suitable compilers and linkers across the target operating systems
and hardware platforms. The emergence of GCC, the GNU compiler collection, and especially the
gcc C and the g++ C++ compilers across multiple platforms and operating systems, has made it
much easier to ensure that computations made using the same source code do not give platform-
dependent output on the same data. This is still not guaranteed, as, for example, time and time zone
handling may differ between operating systems.
The contribution of individuals here is often crucial; the
R
Windows FAQ 3.1.10 reflects this:
'The assistance of Yu Gong at a crucial step in porting R to MinGW-w64 is gratefully acknowl-
edged, as well as help from Kai Tietz, the lead developer of the MinGW-w64 project'.* Without
their important interventions, it would not have been possible to progress with a GCC-based 64-bit
R
for 64-bit Windows platforms. Not infrequently, such interventions occur unexpectedly, suddenly
opening up apparently blocked avenues. Platform-specific open-source projects may use compilers
supplied with operating systems, some of which are available without charge.
Beyond the compilers and linkers provided with GCC, many projects using C also use the legacy
Unix make command to manage the build process and GNU autoconf to configure the build process
by auto-detecting the presence of, and versions of, software dependencies. In addition, many also
use GNU libtool to assist in writing input files for make processes on the fly. Others choose a more
modern open-source build system, CMake; it is, however, rarely the case that experienced open-
source developers feel comfortable in both build environments. It is much easier for developers to
use the same compiler and application build support system across platforms, so that test suites can
be deployed and used in the most convenient way, providing the most consistent environment for
software component development.
Other open-source geospatial projects use Java, which handles cross-platform portability by run-
ning byte-compiled programs on platform-specific virtual machines. Java was often adopted by
projects initiated when the portability of C compilers was in doubt and where developers felt that a
more modern interpreted language was an advantage. JavaScript used as a mechanism for embed-
ding computation in information delivered to web browsers and similar front-end software has
become extremely powerful. The initial Google Maps application programming interface (API)
was written as a JavaScript API but has subsequently been enlarged to include other components.
Before returning briefly to web and mobile geospatial applications, we must note the significance
of other major language environments. Ramsey (2007) mentions those based on .Net, with their use
of the wrapping of C/C++ and Java components. The simplified wrapper and interface generator
(SWIG) has been developed to permit compiled components to be used in scripting languages such
as Perl, Python, PHP, Tcl and Ruby, among others. Some applications have designed customised
interfaces like GRASS with Python; others use system calls out to the operating system to execute
external programs. Shell scripts, known as batch programs on Windows platforms, have long been
a staple form of application integration that have been easy to write and maintain and are likely to
remain of major importance on all platforms; despite appearances, shell scripts are just as conve-
nient on OS X (formerly Mac OS X) platforms as other versions of Unix.
14.2.2 c
oMPonent
S
tackS
Software components appear to have been defined first by McIlroy (1969), as interchangeable subas-
semblies by analogy with mass production manufacturing. A software component should provide
an encapsulated set of related functions, and such components are said to be modular and cohesive.
Components communicate with one another through interfaces, which are specified in such a way
that components can be combined, or stacked, without each programmer being obliged to know the
internals of all the components being integrated. Just as a software component is a set of related
functions, a software stack is a set of related software components.
*
http://cran.r-project.org/doc/manuals/R-admin.html#g_t64_002dbit-Windows-builds.
