exaFOAM/foam-extend4.1-coherent-io
Archived
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Martin, merge

Browse source
This commit is contained in:
Hrvoje Jasak 2010-12-16 07:03:01 +00:00
parent 0a3197c4c3
commit dfba5b5fdc
1 changed files with 56 additions and 136 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

176
ThirdParty/README.ThirdParty vendored
View file

@ -1,183 +1,103 @@
A new design for the ThirdParty packages:
=========================================
The main purpose of this new development is to build a complete ThirParty
packages set for OpenFOAM 1.6-ext using only the original package source
The main purpose of this new development is to build a complete ThirParty packages set for OpenFOAM 1.6-ext using only the original package source
tarball and some patch files ( when necessary).
A useful by-product of this development is also to provide some kind of binary
packaging of the ThirdParty packages.
A useful by-product of this development is also to provide some kind of binary packaging of the ThirdParty packages.
The RPM suite of tools was selected to develop a first prototype.
The whole process needs to run and install in user-space, without the need to
be root for installing the packages.
The whole process needs to run and install in user-space, without the need to be root for installing the packages.
Here is what's available:
a: A set of rpm spec files for specific ThirdParty packages.
b: A suite of bash scripts to automate the complete sequence of downloading,
compiling, installing and generating RPMs.
c: An empty directory structure pre-configured and ready to proceed with the
download, compilation and installation of chosen ThirdParty packages for
OF-1.6-ext.
d: A simple mecanism that allows replacing any of the ThirdParty packages by
a system installed package instead.
Pre-requisite:
--------------
You will need a working installation of the commands 'rpm' and 'rpmbuild' on
your system in order to compile and install the ThirdParty packages.
Please check your system installation first.
b: A suite of bash scripts to automate the complete sequence of downloading, compiling, installing and generating RPMs.
c: An empty directory structure pre-configured and ready to proceed with the download, compilation and installation of
chosen ThirdParty packages for OF-1.6-ext.
Quick description of the main scripts:
--------------------------------------
a: AllMake:
Main wrapper script that will call AllMake.stage0 to AllMake.stage4
scripts in sequence.
Main wrapper script that will call AllMake.stage0 to AllMake.stage4 scripts in sequence.
b: AllMake.stage0:
This script is useful only for populating what I am calling the local
"RPM vault" with pre-generated RPMs. This is the script written to
address the use-case: "I have some pre-generated RPM files, now what"
Basically, you call this script with a list of RPMs generated by the
AllMake.stage(1-4) in order to populate the local RPMS vault.
Once in place, these are the RPMs will be installed instead of
proceeding with the standard compilation process.
This script is useful only for populating what I am calling the local "RPM vault" with pre-generated RPMs.
This is the script written to address the use-case: "I have some pre-generated RPM files, now what"
Basically, you call this script with a list of RPMs generated by the AllMake.stage(1-4) in order to populate the local RPMS vault.
Once in place, these are the RPMs will be installed instead of proceeding with the standard compilation process.
c: AllMake.stage1:
This script is taking care of the basic ThirdParty tools like compilers,
cmake , python, etc. If we ever need to override the local version of
flex or bison, this is where we will add those additional packages.
This stage will also generate a .sh and .csh file one needs to source in
order to initialize the PATH and LD_LIBRARY_PATH env. variable. If you
need to compile the rest of the ThirdParty packages with a new gcc
compiler, you will need to source those .sh or .csh file in before
activating the other AllMake.stage(2-4) scripts.
This script is taking care of the basic ThirdParty tools like compilers, cmake , python, etc.
If we ever need to override the local version of flex or bison, this is where we will add those additional packages.
This stage will also generate a .sh and .csh file one needs to source in order to initialize the PATH and LD_LIBRARY_PATH env. variable.
If you need to compile the rest of the ThirdParty packages with a new gcc compiler, you will need to source those .sh or .csh file in before activating the other
AllMake.stage(2-4) scripts.
d: AllMake.stage2:
This script is taking care of the MPI communication libraries. Right
now, only OpenMPI is supported.
This stage will also generate a .sh and .csh file one needs to source in
order to initialize the PATH and LD_LIBRARY_PATH env. variable. You will
need to source those .sh or .csh file in before activating the other
AllMake.stage(3-4) scripts because some packages depends on the
communication library.
This script is taking care of the MPI communication libraries. Right now, only OpenMPI is supported.
This stage will also generate a .sh and .csh file one needs to source in order to initialize the PATH and LD_LIBRARY_PATH env. variable.
You will need to source those .sh or .csh file in before activating the other AllMake.stage(3-4) scripts because some packages depends on the communication library.
e: AllMake.stage3:
This script is taking care of the "standard" ThirdParty libraries like
metis, scotch, mesquite, etc.
This stage will also generate a .sh and .csh file one needs to source in
order to initialize the PATH and LD_LIBRARY_PATH env. variable. You will
need to source those .sh or .csh file in before compiling OpenFOAM
because some "Make/options" files will refer to environment variable
that are specific to those packages
This script is taking care of the "standard" ThirdParty libraries like metis, scotch, mesquite, etc.
This stage will also generate a .sh and .csh file one needs to source in order to initialize the PATH and LD_LIBRARY_PATH env. variable.
You will need to source those .sh or .csh file in before compiling OpenFOAM because some "Make/options" files will refer to environment variable that are
specific to those packages
f: AllMake.stage4:
This script is taking care of Paraview and QT (and takes an awfull long
time to compile, honest...).
This stage will also generate a .sh and .csh file one needs to source in
order to initialize the PATH and LD_LIBRARY_PATH env. variable. You will
need to source those .sh or .csh file in before compiling OpenFOAM
because some "Make/options" files will refer to environment variable
that are specific to those packages
This script is taking care of Paraview and QT (and takes an awfull long time to compile, honest...).
This stage will also generate a .sh and .csh file one needs to source in order to initialize the PATH and LD_LIBRARY_PATH env. variable.
You will need to source those .sh or .csh file in before compiling OpenFOAM because some "Make/options" files will refer to environment variable that are specific to those packages
g: tools/makeThirdPartyFunctionsForRPM:
A suite of bash functions useful for wrapping the rpmbuild and rpm
commands
A suite of bash functions useful for wrapping the rpmbuild and rpm commands
For every packages, this is the basic process we will be going through when
starting building the ThirdParty packages from scratch:
a: Verify in the local "RPM vault" if a RPM is available for a given
package
For every packages, this is the basic process we will be going through when starting building the ThirdParty packages from scratch::
a: Verify in the local "RPM vault" if a RPM is available for a given package
b: If it is, simply install this RPM and move on to the next package
c: if the RPM is absent:
i: verify if the source tarbal is available from the SOURCES "vault"
ii: if it is not, download the tarball using the specified URL.
iii: proceed with the extraction, patching, configuration,
compilation, RPM generation and installation of the package. The
generated RPM is always used for installation.
d: The default installation root directory is "$WM_THIRD_PARTY_DIR". This
can be overriden though when installing the RPM.
iii: proceed with the extraction, patching, configuration, compilation, RPM generation and installation of the package. The generated RPM is always used for installation.
d: The default installation root directory is "$WM_THIRD_PARTY_DIR". This can be overriden though when installing the RPM.
Relocating the RPM root installation directory:
a: All the generated RPMs can be relocated, meaning that you can override
the hard-coded root installation directory when using those RPMs for
installation.
b: You can check that the RPM is relocatable by using the command rpm -qip
thePackage.rpm. For example, from the cmake-2.8.3 package generated on
one of my machine:
a: All the generated RPMs can be relocated, meaning that you can override the hard-coded root installation directory when using those RPMs for installation.
b: You can check that the RPM is relocatable by using the command rpm -qip thePackage.rpm. For example, from the cmake-2.8.3 package generated on one of my machine:
> rpm -qip cmake-2.8.3-darwinIntelGccDPOpt.i386.rpm| grep Relocations
Name : cmake
Relocations: /Users/beaudoin/Projets/SAMH/OpenFOAM/ThirdParty-1.6-ext-RPM-based
Name : cmake Relocations: /Users/beaudoin/Projets/SAMH/OpenFOAM/ThirdParty-1.6-ext-RPM-based
The Relocations path is the actual location pointed by the
$WM_THIRD_PARTY_DIR on my laptop when I generated the RPM.
It is the indication that the RPM is relocatable. This path will turn to
be hardcoded in the RPM because the environment variable was expanded
before generating the RPM. This is the default root directory where the
RPM will install its "payload". This can be overridden using the 'rpm'
command-line parameter --relocate OLDPATH=NEWPATH .
The Relocations path is the actual location pointed by the $WM_THIRD_PARTY_DIR on my laptop when I generated the RPM.
It is the indication that the RPM is relocatable
This path will turn to be hardcoded in the RPM because the environment variable was expanded before generating the RPM..
This is the default root directory where the RPM will install its "payload"
This can be overridden using the 'rpm' command-line parameter --relocate OLDPATH=NEWPATH .
For example, let's say you want to install the RPM under the root
directory /tmp/someDir instead, you will call the 'rpm' command like this:
For example, let's say you want to install the RPM under the root directory /tmp/someDir instead, you will call the 'rpm' command like this:
rpm -ivh ./cmake-2.8.3-darwinIntelGccDPOpt.i386.rpm \
--relocate /Users/beaudoin/Projets/SAMH/OpenFOAM/ThirdParty-1.6-ext-RPM-based=/tmp/someDir
rpm -ivh ./cmake-2.8.3-darwinIntelGccDPOpt.i386.rpm --relocate /Users/beaudoin/Projets/SAMH/OpenFOAM/ThirdParty-1.6-ext-RPM-based=/tmp/someDir
Even better, you can dig down the hard-coded path even deeper in order to
relocate the whole installation directory, down to the last hard-coded
subdirectory.
Even better, you can dig down the hard-coded path even deeper in order to relocate the whole installation directory, down to the last hard-coded subdirectory.
Just specify the whole path when using the --relocate parameter
So basically, you can install the RPM right under /usr if you want, hence
bypassing the default sequence of package subdirectories I have chosen in
order to stay close to the "traditional" ThirdParty layout.
So basically, you can install the RPM right under /usr if you want, hence bypassing the default sequence of package subdirectories I have chosen in order to stay
close to the "traditional" ThirdParty layout.
9: Using system installed package
It is possible to replace most of the ThirdParty packages by a system
installed version simply by activating some specific environment variables
in your file prefs.sh or prefs.csh.
The files prefs.csh-EXAMPLE and prefs.sh-EXAMPLE provides a list of
environment variables you need to activate in order to use a system
installed version of a given package.
For example, in order to use a system installed version of Scotch, here is
the list of environment variable you must declare in your etc/prefs.sh file
# System installed Scotch
export SCOTCH_SYSTEM=1
export SCOTCH_DIR=path_to_system_installed_scotch
export SCOTCH_BIN_DIR=$SCOTCH_DIR/bin
export SCOTCH_LIB_DIR=$SCOTCH_DIR/lib
export SCOTCH_INCLUDE_DIR=$SCOTCH_DIR/include
When the XXXX_SYSTEM environment variable is activated for package XXXX,
the compilation and installation from the source tarball of the ThirdParty
package will be skipped. Just make sure all the necessary package specific
environment variables are properly initialized, and that the system
installed version of the package is compatible with the version made
available through the source tarball.
10: Things to do:
a: Testing testing testing. This prototype was tested on the following
platforms:
9: Things to do:
a: Testing testing testing. This prototype was tested on the following platforms:
Mac OS X 10.6 (Snow Leopard) (non RPM based)
Ubuntu 10.04 32bit (non RPM based)
Centos 5.5 64bit (RPM based)
OpenSUSE 11.3 64bit (RPM based)
b: Maybe adding some RPM dependencies might be useful. I have not explored
this yet.
b: Maybe adding some RPM dependencies might be useful. I have not explored this yet.
To be continued...
Martin Beaudoin
Last update: December 2010
Novembre 2010