ViewVC logotype

Contents of /branches/ROBW_XPLATFORM/bruce/src/SConscript

Parent Directory Parent Directory | Revision Log Revision Log

Revision 668 - (show annotations)
Sat Mar 25 13:27:27 2006 UTC (15 years, 4 months ago) by robwdcock
File size: 1897 byte(s)
+ 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
  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!

1 Import('*')
3 local_env=env.Copy()
4 py_wrapper_local_env=env.Copy()
5 # Remove the sharedlibrary prefix on all platform - we don't want 'lib' mucking with our python modules
6 del py_wrapper_local_env['SHLIBPREFIX']
8 lib_name = 'bruce'
9 py_wrapper_name = lib_name+'cpp'
10 py_wrapper_source = py_wrapper_name+'.cpp'
11 py_wrapper_lib_name = py_wrapper_name
13 src_dir = local_env.Dir('.').srcnode().abspath
15 import os
16 filenames = os.listdir(src_dir)
17 sources = [x for x in filenames if os.path.splitext(x)[1] in ['.cpp', '.c']]
18 headers = [x for x in filenames if os.path.splitext(x)[1] in ['.h']]
19 # Filter out sources that should not be in the list automatically
20 # Filter out sources that should not be in the list automatically
21 sources.remove(py_wrapper_source) # FIXME: should probably refactor the source tree so the python wrapper isn't colocated with c++ sources
23 local_env.Append(LIBS = [boost_lib, 'escript', 'esysUtils'])
24 py_wrapper_local_env.Append(LIBS = [boost_lib, lib_name, 'escript', 'esysUtils'])
26 lib = local_env.SharedLibrary(lib_name, sources)
27 py_wrapper_lib = py_wrapper_local_env.SharedLibrary( py_wrapper_lib_name, py_wrapper_source)
29 include_path = Dir(lib_name, incinstall)
31 local_env.Install(include_path, headers )
32 local_env.Install(libinstall, lib)
33 py_wrapper_local_env.Install(pyinstall+'/bruce', py_wrapper_lib)
35 # export the lib target since tests will depend on it
36 # the lib target is a list of file nodes (why? win32 produces more than one output file: .lib, .dll, .pdb)
37 # FIXME: This list handling produces the desired result but can this be done directly with scons File nodes?
38 dep_lib = [libinstall+'/'+str(x) for x in lib]
39 Export('dep_lib')
41 # Call the python sconscript
42 env.SConscript(dirs = ['#/bruce/py_src'], build_dir='py', duplicate=0)
44 # Call the unit tests SConscript
45 local_env.SConscript(dirs = ['#/bruce/test'], build_dir='#/build/$PLATFORM/bruce/test', duplicate=0)

  ViewVC Help
Powered by ViewVC 1.1.26