Log of /branches/intelc_win32/scons/nelix_kb_options.py

---

Revision 754 - (view) (annotate) - [select for diffs]
Modified Mon Jun 26 08:00:38 2006 UTC (16 years, 9 months ago) by woo409
File length: 1093 byte(s)
Diff to previous 753

+ 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.

---

Revision 753 - (view) (annotate) - [select for diffs]
Modified Mon Jun 26 02:51:25 2006 UTC (16 years, 9 months ago) by woo409
File length: 1106 byte(s)
Diff to previous 752

+ 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.

---

Revision 752 - (view) (annotate) - [select for diffs]
Modified Mon Jun 26 02:25:41 2006 UTC (16 years, 9 months ago) by woo409
File length: 1093 byte(s)
Diff to previous 748

+ 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.

---

Revision 748 - (view) (annotate) - [select for diffs]
Modified Sat Jun 24 15:09:10 2006 UTC (16 years, 9 months ago) by woo409
File length: 1040 byte(s)
Diff to previous 747

+ 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)?

---

Revision 747 - (view) (annotate) - [select for diffs]
Modified Sat Jun 24 12:58:50 2006 UTC (16 years, 9 months ago) by woo409
File length: 1036 byte(s)
Diff to previous 743

+ 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

---

Revision 743 - (view) (annotate) - [select for diffs]
Added Sat Jun 24 11:44:55 2006 UTC (16 years, 9 months ago) by woo409
File length: 994 byte(s)

+ 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