The Globus Toolkit Windows Port
1.
2.
3.
4.
5.
Revision History ......................................................................................................... 1
Introduction ................................................................................................................. 2
Timeline ...................................................................................................................... 2
Issues and Assumptions .............................................................................................. 2
WinGlobus Distribution .............................................................................................. 3
Flavors............................................................................................................................. 3
Libraries and Executables ............................................................................................... 5
Globus Modules .............................................................................................................. 5
OpenSSL ......................................................................................................................... 6
Build Tree ....................................................................................................................... 6
Distribution ..................................................................................................................... 7
6. Source Code Control ................................................................................................... 7
7. Porting Strategy .......................................................................................................... 8
8. Development Environment ......................................................................................... 9
Microsoft Tools ............................................................................................................... 9
Initial WinGlobus Distribution ....................................................................................... 9
Automated Build Requirements ...................................................................................... 9
Directory Structure........................................................................................................ 10
Special DLL Considerations ......................................................................................... 10
Visual Studio 6.0 vs. Visual Studio.NET ..................................................................... 11
Platform SDK................................................................................................................ 11
Perl ................................................................................................................................ 11
9. Installation/Configuration ......................................................................................... 11
10.
Test ........................................................................................................................ 12
Unit Test........................................................................................................................ 12
System Test ................................................................................................................... 12
11.
Automated Build Procedure .................................................................................. 12
Build Steps .................................................................................................................... 12
Build Files and Directories ........................................................................................... 13
Further Work ................................................................................................................. 17
1. Revision History
Version 1.0
Version 2.0
Version 3.0
Version 4.0
Version 4.0
Initial Entry
Updated, Expanded
Updated
Updated for uniquely
named batch and
makefiles.
Added notes on
Makefile.am, Winmake.am
September 9, 2003
January 13, 2004
March 2, 2004
March 9, 2004
Robert C. Gaffaney
Robert C. Gaffaney
Robert C. Gaffaney
Robert C. Gaffaney
March 9, 2004
Robert C. Gaffaney
2. Introduction
The Globus Toolkit (GTK) is developed in a Linux environment and its primary audience
is Linux and Unix machines.
It is a requirement that the Globus Toolkit also be supported on Win32 Platforms. The
Windows and Linux environments are very different and careful consideration must be
given to reconciling the Runtime and Build differences between the two platforms.
This paper documents the issues, assumptions and strategy for the port of the Globus
Toolkit to Win32 Platforms. Areas covered include Runtime Structure, Distribution,
Installation, Build Process, Development Environment and Tool and others.
An important object is that WinGlobus releases will be concurrent with Unix\Linux
Globus releases. A section of this document will provide instructions on producing a
WinGlobus build from the Globus CVS Archive.
3. Timeline
A port of some of the GTK packages was ported for Version 2.0 of the Toolkit which was
called WinGlobus 2.0. The Win32 distribution has some users, such as Python Globus
(pyGlobus) at Lawrence Berkeley National Laboratory and the Condor project at the
University of Wisconsin. Futures Lab is an indirect consumer of Globus using the
pyGlobus distribution.
A developer has been brought on board specifically to bring the Win32 Port up to the
current release level. Some of the previously ported modules only need to be rebuilt with
updated source files, but some of the modules, notably GSI, were rewritten and need to
be ported anew. Some new modules, e.g. XIO and Callout have been produced and a new
version of GridFTP is in the works. Most of this functionality must be ported to
Windows.
The Statement of Work for this developer was split into three-month objectives and sixmonth objectives. The three-month objectives are focused towards quickly getting new
modules in the hands of current users. This will affect some of the strategies proposed.
The six-month objectives are more focused on putting into place a solid process that will
allow regular WinGlobus releases synchronous with Linux version releases.
4. Issues and Assumptions
A shorter paper was produced in conjunction with this project listing Issues and
Assumptions for the porting effort. The most important findings of that paper are
summarized below and are also discussed in the body of the text.












Native support for Win32 is required, not a Unix environment for Windows such
as Cygwin or Interix.
Development will be done on the Linux side. Win32 efforts will be limited to
porting. There are a few exceptions, notably GSI and XIO, where some Windows
development must be done to reconcile Linux/Win32 differences.
Win32 builds will operate on the same CVS code base.
Win32 GTK releases will be concurrent with Linux GTK releases
The Win32 Port will branch from the trunk in CVS and the porting changes made
“off line”.
The basic approach taken by the WinGlobus 2.0 port will suffice, at least for the
short term.
Most likely, Static Libraries will continue be used in the short-term.
Dynamically Linked Libraries (DLLs) are the definite preference of the pyGlobus
folks and these will be made available to them as soon as possible.
Both Globus threaded and Globus non-threaded versions of the libraries are
required.
Builds will be done using Visual Studio in the short term
An automated build process for windows is a requirement and will be
implemented as part of this effort. This process will be implemented using make
files rather than requiring use of the Visual Studio environment.
Either Visual Studio 6.0 or Visual Studio.NET may be used for development. The
first distribution will use Visual Studio.NET solution and project files. When
makefiles are available these will be used instead.
5. WinGlobus Distribution
Flavors
The Globus Linux/Unix build process utilizes ‘Flavors’ to distinguish various platforms
and build configurations. Each library has a base name corresponding to the module and
an ending specific to the build configuration. The same need to differentiate build
configurations exists on the Windows side.
The following table shows the factors in the Windows Flavors:
Factor
Values
Comment
Globus
Threading
threaded
nonthreaded
Globus Threading Model. “threaded”
causes a globus_config.h to be
included that has
HAVE_WINDOWS_THREADS
defined while “nonthreaded” includes
a globus_config.h with BUILD_LITE
defined instead.
Causes the binaries to be built with
debug information or not. Much of
the compiler optimization is turned
off for debug binaries.
Causes either a static library (.lib) or
dynamic library (.dll) to be built.
Microsoft provides six different
versions of runtime libraries. Mixing
libraries will produce link errors or
cause runtime problems for the
Applications built on Globus so
versions of the libraries needed by
users must be provided.
Configuration debug
release
Library Type
C Runtime
Library
static
dynamic
single threaded (/ML)
single threaded debug (/MLd)
multi threaded (/MT)
multi threaded debug (/MTd)
multi threaded dll (/MD)
multi threaded debug dll (/MDd)
There are forty eight combinations of the above factors. Fortunately only a few specific
Flavors are presently needed. As in for the Linux binaries the various factors are
embedded in the Flavor name. So a typical Flavor names would be “win32relmtthr” for a
Win32 release static library with Globus threading built using the /MT (multithreaded)
runtime library and “win32dbgmddthr” for a Win32 debug DLL with Globus threading
built using /MDd (multithreaded debug dll) runtime library.
As on the Linux side, Flavor Names combine with a library base name to produce the
final name of the binary, for example: libglobus_common_win32dbgmddthr.lib.
The following table shows those Flavors presently supported by the build.
Flavor Name
User
win32dbgmtdthr
win32relmtthr
win32dbgmddthr
win32relmdthr
Condor
Condor
pyGlobus
pyGlobus
Globus
Threading
Threaded
Threaded
Threaded
Threaded
Config
Lib Type
C Runtime
Debug
Release
Debug
Release
Static
Static
Dynamic
Dynamic
/MTd
/MT
/MDd
/MD
The WinGlobus build process, to be described later in this document, supports building
any of the 48 possible combinations of Flavor factors so more Flavors can be added as
necessary.
Libraries and Executables
The WinGlobus build process will be able to produce either static or dynamic libraries,
which users linked with their code to create Globus based applications. The OpenSSL
binaries, ssleay32.dll and libeay32.dll, and link libraries ssleay32.lib and libeay32.lib are
also required by end users and are included with the Globus Distribution.
For Static Libraries the Compiler /C7 debug option will be used, placing the debug
information in the .LIB file.
For Debug Dynamic Link Libraries a separate .PDB file with debugging information will
be produced. Debug Libraries also build a Link Library file (.LIB) which is used at link
time by Applications to resolve externals. These PDB and LIB files have the same name
as the DLL.
Executables also produce PDB files containing debugging information with the same
name as the executable. Note that the Flavor-based naming convention is not used for
Executables.
The following table shows the various binaries in the distribution.
Type
Extension
Description
Static Library
*.LIB
Dynamic Library
Dynamic Library
*.DLL
*.PDB
Dynamic Library
*.LIB
Executable
Executable
*.EXE
*.PDB
Static Library Binary with
embedded debugging info
Dynamic Link Library Binary
(Debug DLL only) Debugging
information for DLL
Import Library needed by
Linker building User’s
Application or DLL.
Executable Binary
(Debug EXE only) Debugging
information for EXE
Globus Modules
WinGlobus only supports a subset of Globus and does not utilized build and packaging
tools. It is therefore possible to save much time in retrieving source code from the CVS
archive by getting only these specific modules:





core
callout
common
gass
gram





gridftp
gsi
io
xio (coming soon)
GridFTP (new version, coming soon)
A spreadsheet, WinGlobusProjects.xls has been created showing which libraries and
executables have been ported within each of the above modules. This spreadsheet will be
posted with this document.
OpenSSL
GSI includes its own version of OpenSSL to which some changes have been made. It was
decided not to port this for technical reasons, but instead to utilize the OpenSSL
distribution from https://www.OpenSSL.org. The standard OpenSSL distribution has
scripts and makefiles to allow it to be built for Win32.
The OpenSSL version that is used in the WinGlobus Distribution is 0.9.7c. GSI did make
use of several functions that were not exported by the OpenSSL binaries. To
accommodate this fact, the OpenSSL Windows build procedure was run to produce the
binaries and definition files, then the definition files were changed to add the needed
exports and the binaries re-linked. These modified binaries are those included in the
distribution.
Besides the binaries, a number of header files from the OpenSSL distribution are needed.
The WinGlobus Build Process is told where the OpenSSL distribution resides and it
moves headers and binaries from the OpenSSL build tree to where they are needed in the
WinGlobus build tree.
Build Tree
WinGlobus tree can be located on any drive and at any directory location on a Windows
machine. The full path and drive are stored in the GLOBUS_LOCATION environment
variable. The following table shows the required WinGlobus build tree.
GlobusLocation
Bin
Lib
Include
Include\OpenSSL
Include\threaded
Full Path to WinGlobus ‘root’
WinGlobus location for DLLs, EXEs and
PDBs, including OpenSSL DLLs.
WinGlobus location for Static Libraries
and Link Libraries including OpenSSL
Link Libraries.
WinGlobus location for all module global
include files.
WinGlobus location for OpenSSL global
include files.
WinGlobus location for globus_config.h
core
with HAVE_WINDOWS_THREADS set.
WinGlobus location for globus_config.h
with BUILD_LITE set.
Globus Core Source Tree
Callout
Common
Gass
Gram
Gridftp
Gsi
Io
Globus Callout Source Tree
Globus Common Source Tree
Globus Gass Source Tree
Globus Gram Source Tree
Globus GridFTP Source Tree
Globus GSI Source Tree
Globus IO Source Tree
Include\nonthreaded
There are .\Win32 directories sprinkled among the Globus Source Directories. These
contain Windows only Source Files, Project Files and solution Files.
Distribution
A WinGlobus.0 Distribution will be created for each of the four defined Flavors. The
binaries for a particular distribution will be created by running the WinGlobus build
procedure then a ZIP archives will be created that is a complete snapshot of the Build
Tree described above, including the binaries and all source files.
As the user base grows it may be desired to make two distributions for each Flavor: one
containing only the binaries, headers and link libraries; and one also containing the
source files also.
6. Source Code Control
The Globus Project uses a CVS Repository for the Globus code base. It is a given that the
WinGlobus releases will build from the same repository.
CVS (Concurrent Versions System) is an open source application and supports multiple
platforms. Windows version of CVS can be downloaded at
http://www.cvshome.org/
WinGlobus created a branch from the trunk of the repository and merged back into the
trunk when changes were complete. This process will be repeated as necessary as XIO
and GridFTP are ported.
Any Windows changes made to the repository, even though they most often reside within
#ifdef WIN32 blocks, require that the both the Linux and Windows distributions be
retested.
As of this writing the WinGlobus port is based on the win32_merge_tag CVS tag. At
some point soon the port should be run against the trunk to catch any bug fixes and/or
new functionality since CVS was tagged for the port.
Futures Lab at MCS had made some changes in their repository for Access Grid. These
changes were captured for the port. The Futures Lab CVS Repository can be found at:
http://fl-cvs.mcs.anl.gov/viewcvs/viewcvs.cgi/
7. Porting Strategy
The Globus Toolkit is a mature offering that had gone through multiple revisions before
the decision was made to port it to Windows. This fact has affected and will continue to
impact the porting strategy. For a brand new multi-platform software package an
Operating System Abstraction would be created to allow the main body of code to call
abstract functions which would then be resolved to OS specific functions by platform
specific modules beneath.
The development history of Globus did not allow the luxury of such an OS abstraction so
in the previous Globus Porting effort conditional compilation blocks of the following
form were embedded in the source files:
#ifdef
TARGET_ARCH_WIN32
Windows Specific Implementation Code
#else
Linux/Unix Specific Implementation
Code
#endif
This porting strategy seems the only practical one given the circumstance and will be
retained. It should be noted that in the various package, various constants were used to
control conditional compilation including: TARGET_ARCH_WIN32, WIN32, _WIN32,
WINDOWS, OPENSSLSYS_WIN32.
In some cases additional header and C source files were added to accommodate Windows
specific definitions or functions that were not convenient to otherwise place in the Linux
source files: winglue.c, winglue.h, wincfg.c, wincfg.h, winrand.c, globus_io_windows.c,
globus_io_winsock.h and others.
In the case of the GSI SysConfig module, the API calls were abstracted via conditional
compilation to either a Linux set or Windows set of calls. This worked quite well and
should be considered as a model for future C Language development.
8. Development Environment
Microsoft Tools
There are Open Source Compilers, Linkers, Make utilities and other tools for the
Windows environment. There are also other commercial products for developing on
Windows. Personal experience, reinforced by Globus Users from ActiveGrid and
Condor, is that developers on Windows platforms use Microsoft tools.
For the present at least, things like MinGW or Borland C++ will not be considered. This
can be reconsidered at a later date if user suggests revising this approach.
Initial WinGlobus Distribution
For schedule reasons, the first WinGlobus port picked up where the WinGlobus 2.0
Alpha port left off. The Visual Studio.NET Integrated Development Environment was
used and Project and Solution files were created for every library and executable module
in the port. The WinGlobusProjects.xls spreadsheet described previously contains
specifics on file names and associated project files.
Experience with the manual Visual Studio builds showed that maintaining Project and
Solution files for the many, many Globus binaries was not only very cumbersome but
error prone as well. This helped us establish goals for a more automated build process as
described in the next section.
Automated Build Requirements
Several approaches to automated WinGlobus builds were examined and a strategy was
developed on the basis of needs versus resources.
Some requirements of this build are:






There should be a unique identifier for every build.
Ideally, this identifier, along with the flavor name and a time stamp, should go
into the version.h files, as it does on the Unix side.
The process should account for dependencies and build things in the proper order.
Ideally, the process would not be list driven, but would use CVS metadata or
browse directories to find module information.
The process should produce a go\no-go output and logfiles to determine what
failed.
Ideally the build process would flow into a go\no-go test suite to check the
functionality of the binaries.
Time likely won’t permit accomplishing all of the above on the first pass, but the process
will be light years ahead of manual Visual Studio builds.
Running CVS-BUILD on the Windows side was investigated, but the lack of Win
versions of Libtool and GPT along with the need to track down and test Windows
versions of the AutoConf tools made short work of this notion.
Visual Studio Command Line Builds were considered, but this requires ongoing
configuration work on the Windows side to track Unix side changes. Also, our partners
said they did not want to upgrade to Visual Studio.NET from VS6. pyGlobus and Condor
expressed a desire to do builds using makefiles
Another factor driving the proposed solution is the need for Flavors on the Windows side
as discussed above. Setting up and maintaining many build configurations for Visual
Studio is tedious and error prone.
Short of running Unix build scripts on Windows, the best way to tie into the Unix process
appears to be at the Makefile.am files. These files enumerate the source files for any
given library or executable and contain the base module name which combines with a
Flavor name to make the name of the binary.
So the strategy identified for Windows builds is to use the Makefile.am files to produce
makefiles that can be used by nmake (MS version of GNU make utility) to produce the
binaries. This is accomplished via a Perl script.
Besides the building of the binaries, checkout from CVS and creation of the zip file must
be accomplished. So the script is used in conjunction with batch files to produce a
complete build process.
A build machine to perform regular builds for WinGlobus has been allocated and the
build process is being installed there. The WinGlobus Build Process is described in more
detail in later section of this document.
Directory Structure
The required directory structure is as described above under WinGlobus
Distribution\Build Tree.
Special DLL Considerations
It should be noted that Dynamic Libraries have different requirements than their Static
counterparts. Since Dynamic Libraries must resolve their externals at link time they need
a list of library dependencies.
They also must have their Exported functions enumerated. Exports may either be defined
in the function prototype and in the declaration of the function using the Microsoft
__declspec(dllexport) keyword or they may be declared in a .DEF file. The first method
would require editing many, many header files and source files to implement, so the DEF
file method is to be preferred for WinGlobus.
Visual Studio 6.0 vs. Visual Studio.NET
The WinGlobus 2.0 Port made used Visual Studio.NET. Unfortunately Microsoft made
significant changes between VS6 and VS.NET and additional changes between Visual
Studio.NET and Visual Studio.NET 2003.
Visual Studio Solution, Workspace and Project files are not backward compatible. Visual
Studio is not able to understand Project files from either .NET version. Furthermore, with
Visual Studio.NET Microsoft eliminated the functionality to export Makefiles.
Fortunately, with the identification of the Batch/Script/Makefile build process the above
issues become moot. nmake will work with any of the three Visual Studio versions
described above.
Platform SDK
The Win32 Platform SDK is another important component of the Windows build
environment. the most current Platform SDK is used to insure inclusion of the newest
system libraries and functionality.
Perl
The automated build process uses Perl scripts. ActiveState Perl has been used for this
development. This may be downloaded from http://ActiveState.com.
CVS
If the source files are to be checked out of the repository a Windows version of CVS is
needed: www.cvshome.org.
SSH
If CVS is used the preferred method of access is using the CVS_RSH option. Setting this
up is beyond the scope of this document: www.openssh.org.
9. Installation/Configuration
The WinGlobus port supports client side functionality (no Services or Drivers), so
applications simply link with the libraries. The project files take care of providing paths
to the libraries and header files, so there is really no configuration (runtime paths and
directories, registry, etc.) required.
For these reasons an Installer such as InstallSheild or Microsoft Installer will not be
needed at least initially.
10. Test
Unit Test
There are a large number of Linux console test applications. These will be ported and
built and used to verify the functionality of the ported libraries. There are a number of
Globus servers at ANL that can be used to test Win32 client side functionality. The
specifics test applications and test functions will be determined during the course of the
porting effort.
System Test
There is a System Test procedure used to verify the Linux/Unix release candidates. A
similar System Test must be developed and run to confirm the overall functionality of
WinGlobus releases. The specifics of this test procedure will be determined during the
course of the porting effort.
11. Automated Build Procedure
Build Steps

Visual Studio, the Platform SDK, CVS, SSH and Perl must be set up on the
machine and operating properly.

Go to the Home directory. ‘Home’ for the Windows build process is
GLOBUS_LOCATION\core\source\win32. The top level batch files and scripts
are located in this directory.

The following procedure only applies if Win32 Dynamic Libraries (DLLs) are to
be built:
o A Linux build must be done with the same code base and for the same
threading model as to be used for the Windows build. This produces a set
of Libraries on the Linux box in the directory
($GLOBUS_LOCATION/INSTALL/lib).
o Then on the Windows box MakeLibParse.bat is customized by the user
and run. This causes a file called libparse.pl to be created and moved to
the Linux box. Libparse.pl is run on the Linux box which causes Exported
symbols files to be created there.
o Then on the Windows box the user customizes a file called
CallMoveExports.bat for his environment. This file is run and causes
MoveExports.bat, which was created by MakeLibParse.pl above, to move
the Export Symbols files from the Linux box to their appropriate place on
the Windows machine.

The Windows distributions include the OpenSSL binaries and include files so it is
not necessary to download and build OpenSSL. If you choose to use the OpenSSL
files from the distribution you may choose to edit the Build batch files to delete
the OpenSSL copy steps. If you choose to build OpenSSL the build process
expects that it has been built ant linked with the modified DEF files described
previously. Make sure you modify setenv.bat file to set SSLLocation environment
variable to the path for your SSL distribution.

The WinGlobus Distribution includes Globus Source Code. This code has been
Tagged as described in the Release Notes. Newer versions of the Source Code or
Source Code from a different branch may or may not have build problems under
Windows. If you choose to build from the CVS Repository, the Globus modules
enumerated previously must be checked out from CVS somewhere on the
machine.

Then the SetEnv.bat file must be customized for the particular build environment.
SetEnv must know the directory where the CVS checkout was done and the
directory where OpenSSL is installed (if necessary. See notes above).

Then BuildAll.bat must be customized for the particular Flavors to be produced
by the build.

When all of the above steps have been done the build process is started by
invoking BuildAll from a command prompt in the .\core\source\win32 directory
as described above.
Build Files and Directories
The files utilized by the build process are described in the table below:
File
Type
Description
WinFlavors
Input
Enumerates all supported flavors. The following
example shows the fields defined for each Flavor:
FlavorName
GlobusThreading
BuildConfig
LibraryType
CRuntimeLib
WinModules
Input
win32dbgmtdthr
threaded
debug
static
MTd
Enumerates all modules to be built. The following
example shows the fields defined for each Module:
ModuleType
SourceLocation
library
\gsi\callback\source\library
Win32Location
\gsi\callback\source\win32
SetEnv.bat
Batch
BuildAll.bat
Batch
Note that this file is arranged in ‘dependency order’ to
insure that libraries and include files needed by any
other modules are in place when their build time
comes.
Batch file to set Globus Location and SSL Location
Environment Variables. Also defines the Revision
Level to be used for the binaries. The last is not
presently utilized but will be.
Top level build batch file. This file does the following
things:







WinCVSBuild.pl
WinCVSBuildLibsFlavor.bat
WinCVSBuildExesFlavor.bat
Makefile.am
Winmake.am
Calls SetEnv to set environment variables
Creates build tree if necessary
Copy Core header files to build tree
Copy OpenSSL header files to build tree
Copy OpenSSL binaries to build tree
Execute WinCVSBuild Script
Call WinCVSBuild batch produced by script
Note that the last two steps are repeated for each
Flavor.
Perl
Script that takes a Flavor, Globus Location and SSL
Location as arguments and produces a make file
(Winmake.mak) for each module defined in the
WinModules file. It then produces the
WinCVSBuild.bat file which will invoke nmake for
each of those make files.
Output Batch file produced by WinCVSBuild.pl to invoke
Batch nmake for each of the Library make files produced by
that script. It also directs output form the make process
to Log files corresponding to the Flavor name. The
Flavor Name is appended to the batch file name so that
the file will not be overwritten by a new Flavor build.
Output Batch file produced by WinCVSBuild.pl to invoke
Batch nmake for each of the Executable make files produced
by that script. It also directs output form the make
process to Log files corresponding to the Flavor name.
The Flavor Name is appended to the batch file name so
that the file will not be overwritten by a new Flavor
build.
Input
Files used by the Linux build process. The are read by
WinCVSBuild.pl to extract names of source files,
common include files and base library names
Input
These files enumerate Windows only source files. They
Winmake_Flavor.mak Output
Make
FlavorName_Lib.log
Output
Log
FlavorName_Exe.log
Output
Log
.\Release
Dir
.\Debug
Dir
BuildResults.log
Output
Log
MakeLibParse.bat
Input
MakeLibParse.pl
Input
Libparse.pl
Output
CallMoveExports.bat
Input
MoveExports.bat
Output
also contain information needed for building DLLs:
Library dependencies and Exports. These are located in
the .\win32 location contained in the WinModules
description block for the module.
Makefiles produced by the WinCVSBuild.pl script.
These are created in the same directory where the unix
source code for the module is located. The Flavor
Name is appended to the make file name so that the file
will not be overwritten by a new Flavor build.
Log files are created in the .\core\source\win32
directory. The contain build results information for all
library modules of a particular Flavor.
Log files are created in the .\core\source\win32
directory. The contain build results information for all
executable modules of a particular Flavor.
Object files and other intermediary or output files for
Release builds are created in this directory which is
created below the directory where the unix source code
is located.
Object files and other intermediary or output files for
Debug builds are created in this directory which is
created below the directory where the unix source code
is located.
Logfile containing list of all modules for which a build
was attempted by BuildAll.bat and the
“SUCCEEDED” or “FAILED” results fot that Build.
A helper batch file to call the MakeLibParse.pl Perl
script with the arguments for the users specific
environment. Must be customized by the user.
A script file that produces a script file to be run on a
Linux machine in the directory where libraries (.so
files) can be found from which Exported Symbols can
be extracted.
Scriptfile produced by MakeLibParse.pl which
produces a list of Exports for each Linux library.
A helper batch file thatcalls MoveExports.bat with the
arguments for the users specific environment. Must be
customized by the user.
A batch file produced by MakeLibParse.pl Perl Script
that moves the Export Symbols file from the Linux
machine to their proper location within the Windows
Buid Tree where they are used to create DEF files for
building Win32 DLLs.
The Winmake.mak files have multiple functions and are called three times by the
WinCVSBuild batch file with the arguments CLEAN, COPY and ALL. CLEAN causes
output and intermediary files to be deleted for a clean build. COPY causes a modules
common include files as designated in Makefile.am to be copied to the
GlobusLocation\Include directory. ALL causes all source files to be compiled and linked.
Parsing Makefile.am files
The Makefile.am files are used by the Linux/Unix builds and are used to collect
information for the Windows builds. The following table shows the tags parsed by the
WinCVSBuild.pl file.
Tag
Use
Sources
xxxx_SOURCES
flavorinclude_HEADERS
lib_LTLIBRARIES
This is actually a macro used by convention on most
Makefile.am files to enumerate the source files used for
a particular library. The script captures the source files
with a .c extension for use in the Windows makefiles.
Some Makefile.am files use the autoconf tags directly
such as globus_common_args_test_SOURCES and
libtest___GLOBUS_FLAVOR_NAME__la_SOURCES.
These are treated the same as Sources by the Parser.
Used by Makefile.am to enumerate global include files.
The Windows script places these in the Makefiles to be
copied from the local directory to a global include
directory where they can be found by other libraries and
applications.
The Windows script uses this file to learn the base name
of a library to be built.
Parsing Winmake.am files
Winmake.am files are used to “take up the difference” between the Linux/Unix builds
and Windows builds. There are for example some windows only source and header files
in the build. The following table shows the tags parsed by the WinCVSBuild.pl file.
Tag
Use
WinSources
Sources
wininclude_HEADERS
flavorinclude_HEADERS
LibDependencies
Identifies Windows only source files that
are in the .\win32 directory.
Identifies Windows only source files that
are in the Linux source directory.
Identifies Windows only global header files
that are in the .\win32 directory.
Identifies Windows only global header files
that are in the Linux source directory.
Libraries on which the target is dependent.
Needed for Programs and Dynamic Library
modules.
ProgramLibDependencies
WinExports
ExportExclusions
Libraries on which a program targets
depend but not libraries in the same
Makefile.am (e.g. globus_url_copy)
Windows only symbols that must be
enumerated as Exports in the DLL DEF
file.
Exports defined on the Linux side that are
not supported by the corresponding
Windows module.
Further Work
As of this writing the WinGlobus Build Process creates Static and Dynamic Libraries. It
also produces Tests and Grid Proxy Utility executable files. Four Flavors are currently
implemented.
There is more work to be done however, including the following items.




Use Version Information – The build script contains a version number argument
that should be used to create a Version.h file for each module. This would cause
build specific information to be built into each module.
CVS Checkout – The build process does not presently do CVS Checkout, which
must be done manually.
Build Zip files – The build process does not presently create the distribution Zip
files.
Configure, Bootstrap – The Linux build process uses other files such as configure
and bootstrap to perform module specific steps. It would be nice to handle these
things automatically, but may not be practical in terms of effort involved.