+ Discussion with Lutz Gross showed the tests to be dependent on the sort order, not escript itself. As a result I've backed out the addition of qsortG. Win32 will fail file comparison tests in run_generators.py (unless it uses its own generated versions). It will also fail ...onContactZero/One (8 of them) tests in run_utilOnFinley.py since the sort order change causes some of the normals to be defined the opposite way around to the reference test orientation since they are defined on the opposite face.

+ Made qsortG usage conditional on USE_QSORTG being defined
Note both altix and win32 fail the test_normal_onFunctionContactOne/Zero tests when using QSORTG.
Perhaps QSORTG isn't stable or altix isn't or I've introduced some other bug...I'll try altix without qsortG and see what happens.
This is becoming painful.

+ Added a qsort.c file which contains a drop in replacement for qsort (call it as qsortG). This one appears to be a stable implementation and the test .msh files on windows have been set up to be the same as unix again except for the exponent digits (3 instead of 2).
With ALL the qsorts replaced with qsortG only two tests fail now on win32:
test_normal_onFunctionOnContactOne
test_normal_onFunctionOnContactZero
Both give wrong result errors.
I will check this same code on the altix (including the use of qsortG and see if Altix has the same problem.

+ Removed the debugging code inserted in an effort to track down a difference in the win32 and linux codes. Turns out the problem is with the Utils.c use of quicksort and the test cases. Quicksort is not guaranteed to be stable (retain array order when comparison is equal) which it isn't on Win32. As a result the output files used for regression tests are different for windows
Still verifying but make sense.

+ Commiting some DEBUGGING code which will need to be removed later. I need to test on both win32 and altix. It appears something is being initialised incorrectly for Finley_ElementFile stuff on win32. I've modified Mesh_line2.c to assist in tracking this down (though it is common to anything that has useElementsOnFace true when constructed).
When I find it this is going to be one seriously stupid and expensive to find bug.

+ run_generators.py now has a commented section that you can uncomment to have it dump out the reference files
+ Win32 output files differ not only in the exponent (e+000 instead of e+00) format but also in order for part of the file. The same code has been compiled on altix and it passes the tests with the original files. I've no idea why the win32 version produces a different order.
THIS REQUIRES FURTHER INVESTIGATION
Does the output file require the lines to be in a specific order (it doesn't appear to effect anything else)?

+ re-enabled all the tests in run_generators.py
+ Fixed up some extra #includes left over from initial port
+ nelix_kb_options.py now has some additional optimisation flags for my notebooks pentium M processor

+ Just turning on and off a few tests in run_generators which is currently producing different order in the outputs for files with contacts. The lines are the same just in a different order. Quite strange.

+ Some additional files for the win32 port
+ The additional test meshes are because windows produces floating point numbers like this 12e+001 where are unix is 12e+01
+ nelix_kb_options.py is my notebooks config file. I've included it as an example of win32 compilation options
+ system_dep.h is there for win32 shared library function export/import macros and also to use the intel mathimf.h library since the standard MS VC++ math.h doesn't have all the necessary functions. NOTE this file must be included before all other headers to prevent inclusion of math.h

A few changes in the build mechanism and the file structure so scons can build release tar files:
* paso/src/Solver has been moved to paso/src
* all test_.py are now run_.py files and are assumed to be passing python tests. they can run by
scons py_tests and are part of the release test set
* escript/py_src/test_ are moved to escript/test/python and are installed in to the build directory
(rather then the PYTHONPATH).
* all py files in test/python which don't start with run_ or test_ are now 'local_py_tests'. they are installed i
by not run automatically.
* CppUnitTest is now treated as a escript module (against previous decisions).
* scons realse builds nor tar/zip files with relvant source code (src and tests in seperate files)
the python tests don't pass yet due to path problems.

+ Fixed incorrect target path in SConstruct file
+ cognac now links with g++ compiled boost rather than intelc compiled boost due to compilation errors with intel c. (Finley will still compile and work with intel c though) - this is the same configuration as the access altix

+ Modified the env (environment) creation for the ia64 platform to include PATH so it no longer complains about not being able to locate the intel compiler. This is related to the previous fix for windows. Seems it is a scons intelc.py bug.

+ Minor modification to how the ENV external environment is initialised. Originally this was done as part of the env = Environment( ENV = ...) construction. Unfortunately this doesn't work properly on windows as it clobbers the path edits performed by the tools = 'intelc'. The end result is icl is not found. Now the env is initialised without the ENV = and they are added in after construction.
I suspect this is a bug in scons itself on the windows platform.

+ NEW BUILD SYSTEM
This commit contains the new build system with cross-platform support.
Most things work are before though you can have more control.
ENVIRONMENT settings have changed:
+ You no longer require LD_LIBRARY_PATH or PYTHONPATH to point to the
esysroot for building and testing performed via scons
+ ACcESS altix users: It is recommended you change your modules to load
the latest intel compiler and other libraries required by boost to match
the setup in svn (you can override). The correct modules are as follows
module load intel_cc.9.0.026
export
MODULEPATH=${MODULEPATH}:/data/raid2/toolspp4/modulefiles/gcc-3.3.6
module load boost/1.33.0/python-2.4.1
module load python/2.4.1
module load numarray/1.3.3

I have changed some of the documentation and added more explanations for
the online reference guide for esys13. I have modified two of the
example source codes to write out the results for Helmholtz problem and
changed one variable name in the diffusion.py code to avoid confusion.

Scons build options for cognac.ivec.org using intel v9.0.026 compilers
Note: Boost is currently not available as a module on cognac. As a result the boost directories used in this build point to my specific boost installation which should be visible to all ivec users. This will get fixed eventually.

The sparse solver can be called by paso now.
the building has been change to reduce some code redundancy:
now all scons SCscripts are importing scons/esys_options.py which
imports platform specific settings.

Some chnages required for oder numarray versions. mai problem is that
operations on array objects with rank 0 sometimes return float rather
than arrays. This problem seems to be fixed in newer releases.