/[escript]/branches/ROBW_XPLATFORM/finley/test/SConscript
ViewVC logotype

Log of /branches/ROBW_XPLATFORM/finley/test/SConscript

Parent Directory Parent Directory | Revision Log Revision Log


Links to HEAD: (view) (annotate)
Sticky Revision:

Revision 676 - (view) (annotate) - [select for diffs]
Modified Sun Mar 26 10:13:34 2006 UTC (13 years, 3 months ago) by robwdcock
File length: 772 byte(s)
Diff to previous 670 , to selected 666
+ Modified test SConscript dependencies to remove redundant call to explicit dependency
+ Modified scon_extensions.py - run unit tests (py and C++) now use scons::Execute rather than python os.system. This ensures the development environment
is used rather than the users environment to run the tests
+ SConstruct file now sets up LD_LIBRARY_PATH and PYTHONPATH to point to the current builds pyinstall and libinstall paths as required.
IT IS NO LONGER NECESSARY TO SET LD_LIBRARY_PATH and PYTHONPATH to point at your build outputs. Much safer in the presence of multiple checked out builds.
Under these circumstances you are better of using scons to run the tests rather than doing so directly. Easiest way to do this is to build the test output target for the test you want:
e.g. scons build/posix/bruce/test/python/ImportTest.passed
or if you prefer
cd build/posix/bruce/test/python
scons -u ImportTest.passed



Revision 670 - (view) (annotate) - [select for diffs]
Modified Sat Mar 25 14:56:39 2006 UTC (13 years, 3 months ago) by robwdcock
File length: 799 byte(s)
Diff to previous 668 , to selected 666
+ Changed include paths to no longer require the cpp suffix (missed in earlier
  commit)
+ modified tests so they no longer install to #/lib


Revision 668 - (view) (annotate) - [select for diffs]
Modified Sat Mar 25 13:27:27 2006 UTC (13 years, 3 months ago) by robwdcock
File length: 1041 byte(s)
Diff to previous 667 , to selected 666
+ finally figured out why the tests failed when the python extension libs were
  no longer sym links. The original setup for python extension modules was to
  have sym links in the esys/* directories named, for example escriptcpp.so.
  These would link to the actual libraries libescriptcpp.so. The lib*.so would
  link to each other. When you replaced the symlink with a copy of the lib*.so
  but renamed without the lib you would then get problems. In particular,
  py_tests would suddenly start failing.

  The problem appears (I've not been able to find documentary evidence to this
  case) to be that when, for example, you import bruce, brucecpp.so imports
  lib/libescriptcpp.so (which intialises escript python bits), bruce then
  imports escriptcpp.so (which also initialised escript python bits).

  Whether that is exactly correct or not is of interest but the important bit
  is you appear to get two versions. After thinking about this for a bit and
  reviewing a bunch of other examples of working python modules I noticed a
  pattern. NONE of the other examples ever included more than the python
  wrapper code in the python extension library. Instead they just link to
  the pure C++ library. This would avoid the duplicate load.

  So, I've refactored the code. If you consider escript the pattern in now:
  lib/libescript.so - which has all of escript EXCEPT the python escriptcpp.cpp
  esys/escript/escriptcpp.so - which has ONLY the escriptcpp.cpp and links to
                               lib/libescript.so
  
  Run the tests and low and behold they all pass again.

  Q: Why doesn't this problem occur with sym links?
  A: My guess is that python and the dynamic linker take a look at the actual
     absolute python of libraries to determine if its a "different" library.
     I did fine some discussions that seem to suggest this.

  Q: Why can't you just set LD_LIBRARY_PATH==PYTHONPATH and stick all the
     libs in that directory?
  A: I (in fact we, Peter Hornby was there) tried. With the renaming of the
     python module so it doesn't have a lib prefix you get problems with
     getting the shared libraries to be looked up in LD_LIBRARY_PATH. Do
     the opposite and use lib on the python modules and you have problems
     with windows which doesn't prepend the lib. Various combination
     in between were also tried but you end up in a catch 22 situation so far
     as I could tell

  Please if you know more about the ins and outs of python and shared
  libraries let me know if this isn't true. I'd really like to know if my
  guesses are correct. In any event, the fix is more consistent with the
  patterns I've seen

  Phew! this was a long log message, glad it is on a branch!




Revision 667 - (view) (annotate) - [select for diffs]
Modified Fri Mar 24 13:25:00 2006 UTC (13 years, 3 months ago) by robwdcock
File length: 1047 byte(s)
Diff to previous 666
+ OUCH ARGHH
+ Okay the wizzy linkHack doesn't work. Not sure why but py_tests fail
when the shared library is on the link line directly (without a -l)

+ Unfortunately we can't figure out how to use -l without it prepending
a lib prefix. Hence all the shareable objects in python now need to be
called libblah.so (and lib will need to be prepended on windows!!!!).
This is not the python way and its very annoying. Why do we have this
problem? Because the C++ shared libraries link with each other.



Revision 666 - (view) (annotate) - [selected]
Modified Fri Mar 24 11:29:40 2006 UTC (13 years, 3 months ago) by robwdcock
File length: 1099 byte(s)
Diff to previous 661
+ Fix up python esys area:
  + libraries are named without lib prefix on posix platforms (python standard)
  + libraries are now installed into the pyinstall area (python standard)
  + symlinks removed, no longer required
  + LD_LIBRARY_PATH is now optional for PYTHON programs (still required for c++)
+ lib PREFIX removal NOTES:
  + removing the lib prefix is non-standard for the linker. As such we've created a
    custom function sharedLinkHack to specify the .so on the link command line
    (as opposed to using -l<archive> which will prepend the lib). This has a
    a small slight of hand for scons which was being to "helpful". Scons
    verifies that when creating a shared libray all objects specified are
    created shareable (e.g. ensure objects are compiler with -fPIC). Since
    we are linking a .so out of the blue we had to wrap it up in a File note
    and flag it as shared.
    Easily done, once you know how. Thankfully this is all wrapped
    up in a simple function (sharedLinkHack) that looks like ordinary scons so
    you will never know!
    



Revision 661 - (view) (annotate) - [select for diffs]
Modified Fri Mar 24 09:13:00 2006 UTC (13 years, 3 months ago) by robwdcock
File length: 1047 byte(s)
Diff to previous 649 , to selected 666
+py_tests now runs. Be patient, it is all of them!!


Revision 649 - (view) (annotate) - [select for diffs]
Added Fri Mar 24 06:07:07 2006 UTC (13 years, 3 months ago) by robwdcock
File length: 960 byte(s)
Diff to selected 666
+Opps, helps if you include the two new files for Finley tests


This form allows you to request diffs between any two revisions of this file. For each of the two "sides" of the diff, enter a numeric revision.

  Diffs between and
  Type of Diff should be a

  ViewVC Help
Powered by ViewVC 1.1.26