Balint Joo
July 24, 2004
--------------------------------------------------------------------------

QDP++/Chroma & BAGEL. AIX/XLC build release notes.
The following need to be built:

	i) Libxml
	ii) QMP
	iii) BAGEL
	iv)  QDP++ 
	 v) Chroma

This build relates to single (32 Bit) builds only. I encountered
xlC difficulties in building 64  bits (probably multiple definitions)



Building Libxml:

Use configure_libxml.sh script (sets configure options).

Edit configure_libxml.sh and set the install path to what you need.
Run configure_libxml.sh (does the configure)
then 
	gmake
	gmake install

Notes: The first GMAKE fail. This is normal, it is because it is trying 
to use the current libxml to compile the libxml docs, and some components
for this are not built.  It is OK to run "gmake install" after the first 
"gmake" fails. It is ugly and it sucks but it works. 

Intriguingly enough for me tho. Using libxml-2.6.6 (find it in 
~bjoo/Devel/SciDAC/packages/libxml-2.6.6.tar.gz) Both the make and the 
make install succeeded.

Building QMP:

Use configure_qmp.sh script (sets configure uptions)
Edit configure_qmp.sh script and set theinstall path that you  need.
Run configure_qmp.sh
then 
	gmake 
	gmake install

NB: Cvs repository contains a new beta version of QMP which is not 
yet integrated with QDP++ and Chroma. Use version qmp1-3-1 instead
for now. This is there in ~bjoo/Devel/SciDAC/packages/qmp

Building BAGEL:
===============

This is a little involved, and feel free to consult the 
README and INSTALL files supplied with BAGEL.

First: Bagel has 2 parts. One is the assembly generator (libbagel)
and the other is the assembly. The toplevel makefile will build everything.

If you use  ~bjoo/Devel/SciDAC/packages/BAGEL-1.3.2.tar it is set up
to build single precision powerIII target (powerIIIs)

If you type gmake it should build.

Then make a directory in your packages directory called bagel_single
and move the header files and the library to it.

In my case:
	mkdir ~bjoo/Devel/SciDAC/install/bagel_single
	cd ~bjoo/Devel/SciDAC/packages/BAGEL.1.3.2/wilson_dslash/lib
	cp libwfmpowerIIIs.a *.h ~bjoo/Devel/SciDAC/install/bagel_single

At the end of this procedure you should have libwfmpowerIIIs.a and a couple
of header files in the BAGEL install directory.

Building QDP++:
===============

Use the configure_qdp++_wilson.sh script.
Edit the ROOT, LIBXML_HOME and QMP_HOME variables to reflect where you
installed the stuff. Set QDP_HOME to where you want to install QDP++.

Then run:

./configure_qdp++_wilson.sh 
gmake 
gmake install

Using the qdp++.tar source in ~bjoo/Devel/SciDAC/packages this build
succeeded without fault.

Building Chroma:
===============

Chroma suffers from several IBM/XLC-isms. For the purposes of getting it
running I have checked out a "clean" version (26 July 2004) and have attempted 
to build it. I describe what I came accross as I built it below and how 
I fixed it. Hopefully this will enable you to compile new versions. If 
you just want to run the stock propagator code you can always just
use the compiled version/source in ~bjoo/Devel/SciDAC/packages/chroma.tar.gz

To configure: use the configure_chroma.sh program
Edit configure_chroma.sh and change the variables QMP_HOME, QDP_HOME, BAGEL_HOME
to reflect where these are installed. Change CHROMA_HOME to where you want to 
install the library and the header files (note installation is not needed
if you just want to use the stock apps. If you want to develop, without
messing with autoconf/automake you probably want to do an installation)

Note also that QMP_HOME and QDP_HOME are not usually needed when building
chroma on the SSE clusters. However, because we use BAGEL, we need to specify
these for IBM's. It's silly of course but what can we do.

Now run: configure_chroma.sh
	 gmake
and optionally: gmake install

If you are using my IBM-ised source you can now go do something else 
for a few hours. If you are building from a "virgin source" you will encounter
some errors. Here are the ones I encountered and how I fixed them:

File: fermact_qprop.cc
	Problems with static void qprop_t
	Solution: remove keyword static on line 34 of fermact_qprop.cc

File: prec_fermact_qprop.cc
	Problems with static void qprop_t
	Solution: remove keyword static on line 29 of fermact_qprop.cc

File: readszinqprop_w.cc
	Problems involving I/O.
	Problem seems to be with the 
	   try {  xml.open(xml_buf) } catch { } c
        clause of readszinqprop_w.cc (around line 75)
        Probably xlC doesn't like opening an XML Reader on an XMLBufferWriter
	(some const cast isn't correct). 
	Needs fixed in QDP++ qdp_xmlio.

	Workaround: Add 
		#include <iostream>
	        #include <string> 
	        #include <sstream>

	above line: #include "chromabase.h"
	
	remove line "#include "qdp_util.h"
	replace with lines: 
		using namespace QDP;
		using namespace std;

	replace : 
		try
                {  
		  xml.open(xml_buf);
                }

	with 
	try {   
         const string bufcontent=xml_buf.str() + "\n";
         istringstream is(bufcontent);
         xml.open(is);
        }

       This mimics the (intended) behaviour of xml.open(xml_buf), but xlC seems to have no problem with xml.open(istream&). It may fail at runtime of course
       but at least the file compiles with this workaround. I am suspicious 
       of the const_casting in the qdp_xmlio.cc file.

File: walldeltapff_w.cc
	Problem with "unqualified static template function"
	Solution: remove static keyword on line 29,57,85, 115 and elsewhere.